Re: Accounting for SHELL in ./configure

[Behdad Esfahbod]

I know all that. :) Check out builds/unix/configure.ac
behdad
http://behdad.org/


On Wed, May 1, 2024 at 4:40 PM Mohammad Akhlaghi 
wrote:

> I had set the 'SHELL' environment variable but still '/bin/sh' was used.
> The only way I could pass my SHELL to the Make command within the
> configure script was through the non-standard hack I mentioned before:
> GNUMAKE="make SHELL=$SHELL"
>
> Autoconf generates the './configure' script automatically though a
> 'configure.ac' file. But I don't see any 'configure.ac' in FreeType's
> source. For example here is the source code of a project that I maintain
> which uses Autoconf:
>
> https://git.savannah.gnu.org/cgit/gnuastro.git/tree
>
> The './configure' script is generated automatically from 'configure.ac'
> when building the tarball (since the configure script is automatically
> generated, we don't keep it under version control).
>
> Cheers,
> Mohammad
>
> On 5/1/24 11:17 PM, Behdad Esfahbod wrote:
> > Scratch that.
> >
> > Where is it exactly failing? On Unix, the build system is essentially
> > autoconf, so it should respect SHELL as you suggest.
> >
> > behdad
> > http://behdad.org/
> >
> >
> > On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod 
> wrote:
> >
> >> Can you check if also setting CONFIG_SHELL helps?
> >>
> >> behdad
> >> http://behdad.org/
> >>
> >>
> >> On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi  >
> >> wrote:
> >>
> >>> The Autoconf-generated configure script, or even CMake, respect SHELL,
> so
> >>> if a user gives it a problematic shell, they won't be able to build
> >>> anything abd many programs will crash.
> >>>
> >>> But please consider the scenario mentioned before: when a user doesn't
> >>> have root permissions to change '/bin/sh', they are left with
> non-standard
> >>> hacks like what I did.
> >>>
> >>> When each program's build system respects 'SHELL', the user is free to
> >>> use any shell they want with any program's build.
> >>>
> >>> Cheers,
> >>> Mohammad
> >>>
> >>>
> >>>
> >>>
> >>> On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod <
> beh...@behdad.org>
> >>> wrote:
> >>>
> >>>> I'm not talking about the user overriding the shell specifically. I'm
> >>>> talking about users who genuinely use a non-POSIX shell as their
> terminal
> >>>> shell. Then just running ./configure would fail if configure was to
> respect
> >>>> $SHELL.
> >>>>
> >>>> Or rather you're saying that only POSIX-compatible shells should set
> >>>> $SHELL.
> >>>> behdad
> >>>> http://behdad.org/
> >>>>
> >>>>
> >>>> On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi <
> moham...@akhlaghi.org>
> >>>> wrote:
> >>>>
> >>>>> Thanks Behdad,
> >>>>>
> >>>>> The problem is that I do not have root permissions on the system with
> >>>>> the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my
> >>>>> programs with a custom shell.
> >>>>>
> >>>>> If the user specifies a wrong shell (not the default '/bin/sh'), it
> is
> >>>>> their own responsibility that it is POSIX-compatible. The same way
> that a
> >>>>> user can give a non-GNU Make executable to the GNUMAKE variable.
> >>>>>
> >>>>> In short, when a user changes defaults, it is their resposibility,
> not
> >>>>> the developer's. So no need to worry about that; the important thing
> is to
> >>>>> give users the freedon to customize for their custom environments
> (as GNU
> >>>>> Autoconf does for example; but Autoconf is not used in FreeType).
> >>>>>
> >>>>> Cheers,
> >>>>> Mohammad
> >>>>>
> >>>>>
> >>>>>
> >>>>> On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod <
> >>>>> beh...@behdad.org> wrote:
> >>>>>
> >>>>>> There's no guarantee that the user's shell is sh-compatible.
> autoconf
> >>>>>> really means sh here, because that's the shell the script is
> written for.
> >>>>>> Just symlink your favor

Re: Accounting for SHELL in ./configure

[Behdad Esfahbod]

Scratch that.

Where is it exactly failing? On Unix, the build system is essentially
autoconf, so it should respect SHELL as you suggest.

behdad
http://behdad.org/


On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod  wrote:

> Can you check if also setting CONFIG_SHELL helps?
>
> behdad
> http://behdad.org/
>
>
> On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi 
> wrote:
>
>> The Autoconf-generated configure script, or even CMake, respect SHELL, so
>> if a user gives it a problematic shell, they won't be able to build
>> anything abd many programs will crash.
>>
>> But please consider the scenario mentioned before: when a user doesn't
>> have root permissions to change '/bin/sh', they are left with non-standard
>> hacks like what I did.
>>
>> When each program's build system respects 'SHELL', the user is free to
>> use any shell they want with any program's build.
>>
>> Cheers,
>> Mohammad
>>
>>
>>
>>
>> On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod 
>> wrote:
>>
>>> I'm not talking about the user overriding the shell specifically. I'm
>>> talking about users who genuinely use a non-POSIX shell as their terminal
>>> shell. Then just running ./configure would fail if configure was to respect
>>> $SHELL.
>>>
>>> Or rather you're saying that only POSIX-compatible shells should set
>>> $SHELL.
>>> behdad
>>> http://behdad.org/
>>>
>>>
>>> On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi 
>>> wrote:
>>>
>>>> Thanks Behdad,
>>>>
>>>> The problem is that I do not have root permissions on the system with
>>>> the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my
>>>> programs with a custom shell.
>>>>
>>>> If the user specifies a wrong shell (not the default '/bin/sh'), it is
>>>> their own responsibility that it is POSIX-compatible. The same way that a
>>>> user can give a non-GNU Make executable to the GNUMAKE variable.
>>>>
>>>> In short, when a user changes defaults, it is their resposibility, not
>>>> the developer's. So no need to worry about that; the important thing is to
>>>> give users the freedon to customize for their custom environments (as GNU
>>>> Autoconf does for example; but Autoconf is not used in FreeType).
>>>>
>>>> Cheers,
>>>> Mohammad
>>>>
>>>>
>>>>
>>>> On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod <
>>>> beh...@behdad.org> wrote:
>>>>
>>>>> There's no guarantee that the user's shell is sh-compatible. autoconf
>>>>> really means sh here, because that's the shell the script is written for.
>>>>> Just symlink your favorite shell to sh then, if it's compatible.
>>>>>
>>>>> behdad
>>>>> http://behdad.org/
>>>>>
>>>>>
>>>>> On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi <
>>>>> moham...@akhlaghi.org> wrote:
>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> I was able to find a cleaner hack by running this command before the
>>>>>> './configure' script:
>>>>>>
>>>>>> export GNUMAKE="make SHELL=$SHELL"
>>>>>>
>>>>>> Afterwards, FreeType successfully ran with my desired shell.
>>>>>>
>>>>>> But generally, it would greatly help those building FreeType from
>>>>>> source
>>>>>> if the configure script accounts for the 'SHELL' environment variable.
>>>>>>
>>>>>> Thanks a lot for all the nice work on FreeType,
>>>>>> Cheers,
>>>>>> Mohammad
>>>>>>
>>>>>> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote:
>>>>>> > Dear Freetype developers,
>>>>>> >
>>>>>> > I was trying to build FreeType from source and noticed that the
>>>>>> > './configure' script does not account for the 'SHELL' environment
>>>>>> and
>>>>>> > will always use '/bin/sh'.
>>>>>> >
>>>>>> > Looking at the source of the './configure' script, I was able to
>>>>>> fix the
>>>>>> > problem by manually adding a 'SHELL=$SHELL' in line 135 of the
>>>>>> > './configure' script:
>>>>>> >
>>>>>> >
>>>>>> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135
>>>>>> >
>>>>>> > Accounting for the user's given SHELL is common in many programs
>>>>>> when
>>>>>> > building from source, so it would be good if you could account for
>>>>>> it in
>>>>>> > future versions of FreeType also.
>>>>>> >
>>>>>> > Cheers,
>>>>>> > Mohammad
>>>>>>
>>>>>>

Re: Accounting for SHELL in ./configure

[Behdad Esfahbod]

Can you check if also setting CONFIG_SHELL helps?

behdad
http://behdad.org/


On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi 
wrote:

> The Autoconf-generated configure script, or even CMake, respect SHELL, so
> if a user gives it a problematic shell, they won't be able to build
> anything abd many programs will crash.
>
> But please consider the scenario mentioned before: when a user doesn't
> have root permissions to change '/bin/sh', they are left with non-standard
> hacks like what I did.
>
> When each program's build system respects 'SHELL', the user is free to use
> any shell they want with any program's build.
>
> Cheers,
> Mohammad
>
>
>
>
> On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod 
> wrote:
>
>> I'm not talking about the user overriding the shell specifically. I'm
>> talking about users who genuinely use a non-POSIX shell as their terminal
>> shell. Then just running ./configure would fail if configure was to respect
>> $SHELL.
>>
>> Or rather you're saying that only POSIX-compatible shells should set
>> $SHELL.
>> behdad
>> http://behdad.org/
>>
>>
>> On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi 
>> wrote:
>>
>>> Thanks Behdad,
>>>
>>> The problem is that I do not have root permissions on the system with
>>> the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my
>>> programs with a custom shell.
>>>
>>> If the user specifies a wrong shell (not the default '/bin/sh'), it is
>>> their own responsibility that it is POSIX-compatible. The same way that a
>>> user can give a non-GNU Make executable to the GNUMAKE variable.
>>>
>>> In short, when a user changes defaults, it is their resposibility, not
>>> the developer's. So no need to worry about that; the important thing is to
>>> give users the freedon to customize for their custom environments (as GNU
>>> Autoconf does for example; but Autoconf is not used in FreeType).
>>>
>>> Cheers,
>>> Mohammad
>>>
>>>
>>>
>>> On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod 
>>> wrote:
>>>
>>>> There's no guarantee that the user's shell is sh-compatible. autoconf
>>>> really means sh here, because that's the shell the script is written for.
>>>> Just symlink your favorite shell to sh then, if it's compatible.
>>>>
>>>> behdad
>>>> http://behdad.org/
>>>>
>>>>
>>>> On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi 
>>>> wrote:
>>>>
>>>>> Hi again,
>>>>>
>>>>> I was able to find a cleaner hack by running this command before the
>>>>> './configure' script:
>>>>>
>>>>> export GNUMAKE="make SHELL=$SHELL"
>>>>>
>>>>> Afterwards, FreeType successfully ran with my desired shell.
>>>>>
>>>>> But generally, it would greatly help those building FreeType from
>>>>> source
>>>>> if the configure script accounts for the 'SHELL' environment variable.
>>>>>
>>>>> Thanks a lot for all the nice work on FreeType,
>>>>> Cheers,
>>>>> Mohammad
>>>>>
>>>>> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote:
>>>>> > Dear Freetype developers,
>>>>> >
>>>>> > I was trying to build FreeType from source and noticed that the
>>>>> > './configure' script does not account for the 'SHELL' environment
>>>>> and
>>>>> > will always use '/bin/sh'.
>>>>> >
>>>>> > Looking at the source of the './configure' script, I was able to fix
>>>>> the
>>>>> > problem by manually adding a 'SHELL=$SHELL' in line 135 of the
>>>>> > './configure' script:
>>>>> >
>>>>> >
>>>>> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135
>>>>> >
>>>>> > Accounting for the user's given SHELL is common in many programs
>>>>> when
>>>>> > building from source, so it would be good if you could account for
>>>>> it in
>>>>> > future versions of FreeType also.
>>>>> >
>>>>> > Cheers,
>>>>> > Mohammad
>>>>>
>>>>>

Re: Accounting for SHELL in ./configure

[Behdad Esfahbod]

I'm not talking about the user overriding the shell specifically. I'm
talking about users who genuinely use a non-POSIX shell as their terminal
shell. Then just running ./configure would fail if configure was to respect
$SHELL.

Or rather you're saying that only POSIX-compatible shells should set $SHELL.
behdad
http://behdad.org/


On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi 
wrote:

> Thanks Behdad,
>
> The problem is that I do not have root permissions on the system with the
> faulty '/bin/sh': I cannot change '/bin/sh' and need to build my programs
> with a custom shell.
>
> If the user specifies a wrong shell (not the default '/bin/sh'), it is
> their own responsibility that it is POSIX-compatible. The same way that a
> user can give a non-GNU Make executable to the GNUMAKE variable.
>
> In short, when a user changes defaults, it is their resposibility, not the
> developer's. So no need to worry about that; the important thing is to give
> users the freedon to customize for their custom environments (as GNU
> Autoconf does for example; but Autoconf is not used in FreeType).
>
> Cheers,
> Mohammad
>
>
>
> On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod 
> wrote:
>
>> There's no guarantee that the user's shell is sh-compatible. autoconf
>> really means sh here, because that's the shell the script is written for.
>> Just symlink your favorite shell to sh then, if it's compatible.
>>
>> behdad
>> http://behdad.org/
>>
>>
>> On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi 
>> wrote:
>>
>>> Hi again,
>>>
>>> I was able to find a cleaner hack by running this command before the
>>> './configure' script:
>>>
>>> export GNUMAKE="make SHELL=$SHELL"
>>>
>>> Afterwards, FreeType successfully ran with my desired shell.
>>>
>>> But generally, it would greatly help those building FreeType from source
>>> if the configure script accounts for the 'SHELL' environment variable.
>>>
>>> Thanks a lot for all the nice work on FreeType,
>>> Cheers,
>>> Mohammad
>>>
>>> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote:
>>> > Dear Freetype developers,
>>> >
>>> > I was trying to build FreeType from source and noticed that the
>>> > './configure' script does not account for the 'SHELL' environment and
>>> > will always use '/bin/sh'.
>>> >
>>> > Looking at the source of the './configure' script, I was able to fix
>>> the
>>> > problem by manually adding a 'SHELL=$SHELL' in line 135 of the
>>> > './configure' script:
>>> >
>>> >
>>> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135
>>> >
>>> > Accounting for the user's given SHELL is common in many programs when
>>> > building from source, so it would be good if you could account for it
>>> in
>>> > future versions of FreeType also.
>>> >
>>> > Cheers,
>>> > Mohammad
>>>
>>>

Re: Accounting for SHELL in ./configure

[Behdad Esfahbod]

There's no guarantee that the user's shell is sh-compatible. autoconf
really means sh here, because that's the shell the script is written for.
Just symlink your favorite shell to sh then, if it's compatible.

behdad
http://behdad.org/


On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi 
wrote:

> Hi again,
>
> I was able to find a cleaner hack by running this command before the
> './configure' script:
>
> export GNUMAKE="make SHELL=$SHELL"
>
> Afterwards, FreeType successfully ran with my desired shell.
>
> But generally, it would greatly help those building FreeType from source
> if the configure script accounts for the 'SHELL' environment variable.
>
> Thanks a lot for all the nice work on FreeType,
> Cheers,
> Mohammad
>
> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote:
> > Dear Freetype developers,
> >
> > I was trying to build FreeType from source and noticed that the
> > './configure' script does not account for the 'SHELL' environment and
> > will always use '/bin/sh'.
> >
> > Looking at the source of the './configure' script, I was able to fix the
> > problem by manually adding a 'SHELL=$SHELL' in line 135 of the
> > './configure' script:
> >
> >
> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135
> >
> > Accounting for the user's given SHELL is common in many programs when
> > building from source, so it would be good if you could account for it in
> > future versions of FreeType also.
> >
> > Cheers,
> > Mohammad
>
>

Re: Creating a FreeType GitLab merge request

[Behdad Esfahbod]

Hi David,

As mentioned on the issue, the main thing I like to see you address is,
instead of walking all subtables, only walk subtables from 'kern' features.

behdad

On Tue, Jan 23, 2024 at 10:43 AM David Saltzman 
wrote:

> it might be useful to add (also) either compile-time or runtime switch to
>> hb-based gpos-kerning
>>
>
> I just pushed an update to the merge request to add a config
> flag TT_CONFIG_OPTION_GPOS_KERNING and set it to default to disabled when
> HarfBuzz is available. Users of HarfBuzz can/should use hb_shape instead to
> get full shaping support. Let me know if you have further thoughts/feedback
> on that.
>
> On Mon, Jan 22, 2024 at 1:41 PM Hin-Tak Leung 
> wrote:
>
>> Yes, that sounds quite reasonable. Yes, harfbuzz is big and not everybody
>> needs/wants all of it. To guard against bitrot, it might be useful to add
>> (also) either compile-time or runtime switch to hb-based gpos-kerning
>> looking up along the same code path, just to make sure that this new code
>> doesn't bitrot?
>>
>> If that's done, there is a problem of which to use by default... but then
>> we already have conditionals on harfbuzz being available, etc, so it is
>> probably easy enough to just piggyback on that conditional.
>>
>> On Monday, 22 January 2024 at 20:35:17 GMT, David Saltzman <
>> davidbsaltz...@gmail.com> wrote:
>>
>>
>> this seems to duplicate functionality in harfbuzz, and also a mere
>> subset, for that matter?
>>
>> Yes, that's a good question. For the product I'm working on, we wanted to
>> add kerning support, and we already used FreeType but not HarfBuzz, and our
>> font had GPOS kerning but not a kern table. We first tried just using
>> FreeType's kerning API, before learning that wouldn't work because of kern
>> tables vs GPOS. So then we tried integrating HarfBuzz, since that seemed to
>> be the standard solution. However, after integrating that, even with
>> HB_TINY and some custom modifications to trim it, that was too large and
>> slow for this device; this is on an embedded device with limited
>> flash/ram/processing speed. We have no plans to add languages that require
>> more advanced shaping that would require HarfBuzz anyway, so it'd
>> inevitably add a lot of unnecessary overhead. Another option was to use a
>> script to modify the font to convert the GPOS table to a kern table, then
>> use unmodified FreeType's kerning function; that option worked as well,
>> though the font files ended up larger. So for a product like this, it's
>> valuable to have GPOS kerning support in FreeType.
>>
>> it is also not unheard of to maintain a semi-permanent set of patches for
>> freetype deemed unsuitable for upstreaming
>>
>> We do have our own copy of FreeType anyway, so we could just maintain the
>> patch there and drop this merge request for open sourcing the GPOS kerning
>> implementation if it's decided against taking it. It wouldn't impact us
>> either way, but a co-worker asked to upstream this one for anyone else who
>> may benefit from it.
>>
>> On the other hand, the dysfunctional kerning API, which exists, is
>> misleading
>>
>> Yes, if FreeType's kerning API had just worked for our GPOS font, that
>> would've saved us from going down this rabbit hole of kern tables and GPOS
>> tables, and we could've remained blissfully ignorant with everything just
>> working easily. So it would be nice to save others from that :). Another
>> anecdote is that we also then realized that a previous product which had
>> added kerning support through the FreeType API with its old font ended
>> up losing kerning after the font was swapped out for one with kerning in
>> the GPOS table, and we had shipped that update without noticing the loss;
>> so FreeType supporting GPOS kerning as well could help prevent issues like
>> that.
>>
>> The line could be drawn exactly there at the existing API. the scope of
>> the change should be clearly defined.
>>
>> Drawing the line at the existing API, so leaving the scope at
>> kerning-only and not planning to add support for other GPOS features like
>> x-placement etc, sounds good to me.
>>
>> David
>>
>> On Mon, Jan 22, 2024 at 12:01 PM Alexei Podtelezhnikov <
>> apodt...@gmail.com> wrote:
>>
>>
>>
>>
>> On Jan 22, 2024, at 12:45, Hin-Tak Leung 
>> wrote:
>>
>> FWIW, this seems to duplicate functionality in harfbuzz, and also a mere
>> subset, for that matter?
>>
>>
>> On the other hand, the dysfunctional kerning API, which exists, is
>> misleading. Partial GPOS support to fulfill the API promise is not a bad
>> idea. The line could be drawn exactly there at the existing API.
>>
>> I agree that the scope of the change should be clearly defined.
>>
>>

Re: The current state of rendering and overlap

[Behdad Esfahbod]

On Tue, Dec 19, 2023 at 1:02 PM Skef Iterum  wrote:

> CFF2 is released, has been for years. As far as I know there's no solid
> convention for ignoring unrecognized operators in a CharString, so this
> would be CFF2 minor 1 at best. Which would be years out in terms of
> support.
>
> Practically speaking I don't think this could wind up being a "this
> glyph has overlap" flag, as in CFF2 overlap is valid anywhere. If
> something were added it would be more like a "this glyph doesn't have
> overlap, you can optimize the rendering" flag.
>
> Behdad - there's no provision for a relevant flag in VARC currently,
> correct? (I'm not sure there was one in the glyf-based system, as I
> don't remember a place where the flag would have lived.)
>

Correct.



> Skef
>
> On 12/19/23 10:53, Alexei Podtelezhnikov wrote:
> > Why? The sequence 0x0c  0x40 is reserved and not used for example.
> >
> >
> >> I'm afraid the horse has left the barn as far as that goes.
> >>
> >> Skef
> >>
> >>> On 12/19/23 04:23, Alexei Podtelezhnikov wrote:
> >>> I would suggest that CFF2 invent a special charstring to mark overlaps
> >>> with FT_OUTLINE_OVERLAP only when necessary. Let us know to implement
> >>> it in FreeType.
>
>

Re: The current state of rendering and overlap

[Behdad Esfahbod]

On Tue, Dec 19, 2023 at 11:25 AM Alexei Podtelezhnikov 
wrote:

>
> Note that freetype does not use the overlap flags to determine the path
> fill rule (winding vs even-odd), it always uses winding for TT or CFF2
> variable fonts, as the spec mandates; the discussion here is about freetype
> using the (TT glyf only) overlap flags to enable what Alexei calls "4x4
> bilevel oversampling" in order to mitigate the effects of increased pixel
> coverage where paths overlap inside a glyph. I'm just summarizing the above
> linked fonttools issue, but I don't fully understand the technical details
> of this rendering technique.
> CFF2 doesn't have an equivalent mechanism to say "this glyph may contain
> overlaps", which prompted this specific email thread.
>
>
> CFF was even-odd. CFF2 is non-zero winding.
>>
>> This is about the coverage calculation rather than the  fill rule.
> Suppose two contours cover half-pixel each. The integral coverage depends
> on how they overlap over that pixel. The only way to reasonably deal with
> it is oversampling.
>

I might be wrong, but I think cairo simplifies the shape, merging the
overlaps.

Re: The current state of rendering and overlap

[Behdad Esfahbod]

CFF was even-odd. CFF2 is non-zero winding.

behdad
http://behdad.org/


On Tue, Dec 19, 2023 at 9:50 AM Hin-Tak Leung 
wrote:

> This is the same as the winding rule concept (overlap once = wounded
> twice) ... I seem to remember one of them is even-odd and the other is
> non-zero, and quite fundamental difference between truetype and cff.
>
> On Tuesday, 19 December 2023 at 13:54:21 GMT, Alexei Podtelezhnikov <
> apodt...@gmail.com> wrote:
>
>
>
> 
>
> It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a
>
> CFF2 font. Whether that makes sense is one thing I'd like advice about.
>
> There's currently no such code.
>
>
> I would suggest that CFF2 invent a special charstring to mark overlaps
> with FT_OUTLINE_OVERLAP only when necessary. Let us know to implement
> it in FreeType.
>
>
> https://www.w3.org/TR/WOFF2/#p1
>
> WOFF2 is moving towards accepting explicit overlap flags. Perhaps CFF2 can
> spare  a reserved operator or a two-byte operator.
>

Re: [IDEA] Facilities to extract TT fonts from TTC font collections

[Behdad Esfahbod]

If you don't need to do this from C necessarily, check out ftCLI:

  https://github.com/ftCLI/FoundryTools-CLI

Or "fonttools ttLib --help" from fonttools:

  https://github.com/fonttools/fonttools

behdad
http://behdad.org/


On Mon, Oct 23, 2023 at 6:44 AM Francesco Pretto  wrote:

> Hello,
>
> I recently had to extract a TrueType font from a TTC font collection
> as part of fixing bugs in the podofo library[1]. Since I couldn't find
> an API suited for the task, I found myself in need to manually parse
> the TTC Header, which is not a type exposed in the FreeType public
> API. I believe FreeType could have helped me much better if, for
> example, it would have provided a way to extract the actual face Table
> Directory[2] from the font data. For example, a special tag TTAG_tdir
> could be defined to access the raw Table Directory data with
> FT_Load_Sfnt_Table, like the following:
>
> FT_ULong size = 0;
> FT_Load_Sfnt_Table(face, TTAG_tdir, 0, NULL, );
>
> Interestingly enough, Windows GetFontData[3] seems to do something
> similar (but with inverted semantics) when using the special table
> "0", while to access whole file in case of collections it uses the
> special ttcf "table tag".
>
> Since I already crafted my own solution, I'm not in a rush for
> improvements in FreeType, but it could be something good to have in a
> future release.
>
> Regards,
> Francesco
>
> [1]
> https://github.com/podofo/podofo/blob/df36740b176fa535a8dc6dfc5a1b940f84710aa8/src/podofo/private/FreetypePrivate.cpp#L177
> [2]
> https://learn.microsoft.com/en-us/typography/opentype/spec/otff#table-directory
> [3]
> https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata
>
>

Re: Progress update on alternative rendering engines project

[Behdad Esfahbod]

I don't think this (caching flatten outlines) is a good idea. Pretty much
all serious implementations cache the rendered image. And pretty much all
uses of FreeType don't render the entire glyph set. And must
implementations care a lot more about loading performance. I know you are
suggesting new API. I just don't see how this is useful, unless I'm
misunderstanding it.

behdad
http://behdad.org/


On Sun, Oct 8, 2023 at 12:59 PM Anurag Thakur <
anurag105cse...@bpitindia.edu.in> wrote:

> Here's a detailed explanation for my implementation:
>
> The "preloading" optimization has a simple concept: Load the glyph data
> and perform curve flattening at load time, to reduce render time.
>
> In FreeType terminology, we are moving FT_Load_Glyph​ and
> FT_Decompose_Outline​ calls to FT_New_Face​, so that they only have to be
> performed
> once per glyph and every subsequent invocation can directly call
> FT_Render_Glyph.
>
> So for every call to FT_Render_Glyph​ we don't have to perform the
> "cubic_to" and "conic_to" calculations.
> It's a tradeoff between memory usage and rendering speed.
>
> This is essentially what my implementation does, I have created a function
> FT_New_Face2 which checks for the PRELOAD​ flag.
> Once the face creation succeeds, if the flag is present it iterates
> through all the glyphs in the face and calls FT_Load_Glyph on them​.
> An array of GlyphSlots (glyph_array) is created under the face​ struct to
> store this data.
>
> After this, curve flattening is performed and the resulting lines are
> stored.
>
> To store the line data I added FT_PreLine​ to FT_GlyphSlot​ that
> represents a linkedlist of from​ and to​ points for each line.
>
> The user simply has to call FT_Render_Glyph to get the output, which
> simply iterates over the "prelines" linkedlist and calls "line_to"
>
> To get the data they have to access the GlyphSlot by
> face->glyph_data[glyph_index]​
>
> The current implementation does not support changing the font size, it has
> to be specified during the New_Face call
>
> fontdue implements this by choosing a fixed size to perform curve
> flattening at and then scaling the lines for user
> provided sizes, however this leads to jagged edges at very high
> resolutions.
>
>
> To benchmark the rendering I have replaced the FT_Load_Glyph calls with
> FT_Refresh_Glyph function whose only job is to clear the bitmap
> data and set the correct format for the GlyphSlot since FT_Rendering an
> already rendered glyph did not work.
>
> This approach also does not support font hinting (as is the case with
> fontdue) and I am unsure if/how it could be supported.
>
> I have tried to be minimally invasive with this change, however in my
> opinion the design is too different from the current FreeType API and is
> probably not worth the
> extra effort for the ~5% gain it provides in performance.
>
>
> I have also implemented SIMD optimizations from fontdue and added support
> for ARM NEON, benchmarks attached.
>
> As for the line drawing optimizations, the algorithm is actually pretty
> similar. I was unable to get any improvements from it in my testing, so did
> not implement it.
>
> > I was actually hoping that you would find some
> > interesting ideas in Pathfinder, etc in the line drawing algorithms.
>
> I haven't looked at pathfinder yet because it seemed more GPU focused. I
> did try searching for other algorithms but couldn't find any.
> All the searches lead to some variant of the same algorithm.
>
> I do have 1 optimization in mind though, since the drawing buffer in the
> dense module is an array, it should be suitable for multithreading. The
> lines could be drawn all at once instead of
> sequentially. Is multithreading acceptable for FreeType?
>
>
> Now that I have explored most optimizations I could find, I am working on
> cleaning up the git history and my final report.
>
> Regards
> Anurag
>
>
> --
> *From:* Anurag Thakur
> *Sent:* Wednesday, October 4, 2023 2:57 AM
> *To:* freetype-devel@nongnu.org 
> *Subject:* Progress update on alternative rendering engines project
>
> Hi all,
>
> Here's a quick update on the project status:
>
> I have implemented the "preloading" optimization where FreeType can
> perform curve flattening at load time to reduce render
> time later.
> Although the difference in performance seems to be very little (since the
> accumulation part takes the majority of rendering time)
> (benchmarks attached).
>
> I am almost done with the rendering algorithm improvement from fontdue as
> well. Benchmarks coming soon.
>
> Will send a more detailed report explaining my implementation in detail
> later today and then will work towards the final submission.
>
> Regards,
> Anurag
>

Re: ReactOS: stack vs heap

[Behdad Esfahbod]

On Mon, Sep 4, 2023 at 8:27 PM Werner LEMBERG  wrote:

>
> > Upon further investigation, I think my proposed change is correct.
>
> Thanks a lot, committed!
>

Thanks. One thing I don't understand, is the "+ 2" in the code below:

  AF_LatinBlue  blue_sorted[AF_BLUE_STRINGSET_MAX_LEN + 2];





  for ( i = 0; i < axis->blue_count; i++ )
blue_sorted[i] = >blues[i];

If that + 2 is correct to be there, then we need a similar + 2 in aflatin.h
for blues. But I cannot see why it's needed.

Re: ReactOS: stack vs heap

[Behdad Esfahbod]

Upon further investigation, I think my proposed change is correct.

behdad
http://behdad.org/


On Mon, Sep 4, 2023 at 4:26 PM Behdad Esfahbod  wrote:

> What I said is wrong. But the blues array should be dynamically allocated,
> and use a embedded version for small values. I'll work on it.
>
> behdad
> http://behdad.org/
>
>
> On Mon, Sep 4, 2023 at 3:47 PM Behdad Esfahbod  wrote:
>
>> On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod  wrote:
>>
>>> On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov <
>>> apodt...@gmail.com> wrote:
>>>
>>>> >
>>>> > Wanted to point out that compiling with gcc and adding
>>>> "-stack-usage=2000" to get reports about stacks larger than 2000 bytes is
>>>> probably the easiest way to track down large stacks at the moment. Note
>>>> that af_cjk_metrics_init_widths (44480 bytes) and
>>>> af_latin_metrics_init_widths (52992 bytes) are by far the largest.
>>>> cf2_interpT2CharString (27520 bytes) is also surprisingly large. There are
>>>> a few others like the rasterizer stacks that are between 10-20kb which one
>>>> may also want to look into, but these have been less problematic on my
>>>> experience (though that may have been due to the even larger stacks being
>>>> allocated first). Just wanted to point out how to measure and that the
>>>> rasterizer might not be the first place to look.
>>>>
>>>> That is surprisingly large. Someone should examine how much of it is
>>>> actually used. The rendering pool of "visited cells" (pixels) is
>>>> rather predictable for a given outline. That is why it is easy for me.
>>>>
>>>
>>> I took a look at the autohinter one. The problem comes from:
>>>
>>> AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX];
>>>
>>> in struct  AF_LatinAxisRec_. The value of AF_BLUE_STRINGSET_MAX is ~260.
>>>
>>> My gut feeling is that that's a typo and should be:
>>>
>>>  AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX_LEN];
>>>
>>> where AF_BLUE_STRINGSET_MAX_LEN is 8. I haven't tested that.
>>>
>>
>> Same thing in afcjk.h.
>>
>> I'm finding these using:
>>
>> $ make CPPFLAGS=-Wframe-larger-than=4096
>>
>

Re: ReactOS: stack vs heap

[Behdad Esfahbod]

What I said is wrong. But the blues array should be dynamically allocated,
and use a embedded version for small values. I'll work on it.

behdad
http://behdad.org/


On Mon, Sep 4, 2023 at 3:47 PM Behdad Esfahbod  wrote:

> On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod  wrote:
>
>> On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov 
>> wrote:
>>
>>> >
>>> > Wanted to point out that compiling with gcc and adding
>>> "-stack-usage=2000" to get reports about stacks larger than 2000 bytes is
>>> probably the easiest way to track down large stacks at the moment. Note
>>> that af_cjk_metrics_init_widths (44480 bytes) and
>>> af_latin_metrics_init_widths (52992 bytes) are by far the largest.
>>> cf2_interpT2CharString (27520 bytes) is also surprisingly large. There are
>>> a few others like the rasterizer stacks that are between 10-20kb which one
>>> may also want to look into, but these have been less problematic on my
>>> experience (though that may have been due to the even larger stacks being
>>> allocated first). Just wanted to point out how to measure and that the
>>> rasterizer might not be the first place to look.
>>>
>>> That is surprisingly large. Someone should examine how much of it is
>>> actually used. The rendering pool of "visited cells" (pixels) is
>>> rather predictable for a given outline. That is why it is easy for me.
>>>
>>
>> I took a look at the autohinter one. The problem comes from:
>>
>> AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX];
>>
>> in struct  AF_LatinAxisRec_. The value of AF_BLUE_STRINGSET_MAX is ~260.
>>
>> My gut feeling is that that's a typo and should be:
>>
>>  AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX_LEN];
>>
>> where AF_BLUE_STRINGSET_MAX_LEN is 8. I haven't tested that.
>>
>
> Same thing in afcjk.h.
>
> I'm finding these using:
>
> $ make CPPFLAGS=-Wframe-larger-than=4096
>

Re: ReactOS: stack vs heap

[Behdad Esfahbod]

On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod  wrote:

> On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov 
> wrote:
>
>> >
>> > Wanted to point out that compiling with gcc and adding
>> "-stack-usage=2000" to get reports about stacks larger than 2000 bytes is
>> probably the easiest way to track down large stacks at the moment. Note
>> that af_cjk_metrics_init_widths (44480 bytes) and
>> af_latin_metrics_init_widths (52992 bytes) are by far the largest.
>> cf2_interpT2CharString (27520 bytes) is also surprisingly large. There are
>> a few others like the rasterizer stacks that are between 10-20kb which one
>> may also want to look into, but these have been less problematic on my
>> experience (though that may have been due to the even larger stacks being
>> allocated first). Just wanted to point out how to measure and that the
>> rasterizer might not be the first place to look.
>>
>> That is surprisingly large. Someone should examine how much of it is
>> actually used. The rendering pool of "visited cells" (pixels) is
>> rather predictable for a given outline. That is why it is easy for me.
>>
>
> I took a look at the autohinter one. The problem comes from:
>
> AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX];
>
> in struct  AF_LatinAxisRec_. The value of AF_BLUE_STRINGSET_MAX is ~260.
>
> My gut feeling is that that's a typo and should be:
>
>  AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX_LEN];
>
> where AF_BLUE_STRINGSET_MAX_LEN is 8. I haven't tested that.
>

Same thing in afcjk.h.

I'm finding these using:

$ make CPPFLAGS=-Wframe-larger-than=4096

Re: ReactOS: stack vs heap

[Behdad Esfahbod]

On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov 
wrote:

> >
> > Wanted to point out that compiling with gcc and adding
> "-stack-usage=2000" to get reports about stacks larger than 2000 bytes is
> probably the easiest way to track down large stacks at the moment. Note
> that af_cjk_metrics_init_widths (44480 bytes) and
> af_latin_metrics_init_widths (52992 bytes) are by far the largest.
> cf2_interpT2CharString (27520 bytes) is also surprisingly large. There are
> a few others like the rasterizer stacks that are between 10-20kb which one
> may also want to look into, but these have been less problematic on my
> experience (though that may have been due to the even larger stacks being
> allocated first). Just wanted to point out how to measure and that the
> rasterizer might not be the first place to look.
>
> That is surprisingly large. Someone should examine how much of it is
> actually used. The rendering pool of "visited cells" (pixels) is
> rather predictable for a given outline. That is why it is easy for me.
>

I took a look at the autohinter one. The problem comes from:

AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX];

in struct  AF_LatinAxisRec_. The value of AF_BLUE_STRINGSET_MAX is ~260.

My gut feeling is that that's a typo and should be:

 AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX_LEN];

where AF_BLUE_STRINGSET_MAX_LEN is 8. I haven't tested that.

CFF loading overhead in tracing

[Behdad Esfahbod]

Hi,

In benchmarking FreeType face loading, I noticed that the following two
loops take considerable time when loading CFF1 face:


--- a/src/cff/cffobjs.c
+++ b/src/cff/cffobjs.c
@@ -695,8 +695,8 @@


   FT_TRACE4(( "  %5d ", idx + 390 ));
-  for ( l = 0; l < s1len; l++ )
-FT_TRACE4(( "%c", s1[l] ));
+  //for ( l = 0; l < s1len; l++ )
+//FT_TRACE4(( "%c", s1[l] ));
   FT_TRACE4(( "\n" ));
 }

@@ -710,8 +710,8 @@


   FT_TRACE4(( "  %5d ", cff->num_strings + 390 ));
-  for ( l = 0; l < s1len; l++ )
-FT_TRACE4(( "%c", s1[l] ));
+  //for ( l = 0; l < s1len; l++ )
+//FT_TRACE4(( "%c", s1[l] ));
   FT_TRACE4(( "\n" ));
 }
   }


I don't have tracing enabled, but the compiler doesn't seem to have wiped
away the loop. I'm not sure why. At any rate, I wonder if these can be
guarded by FT_DEBUG_TRACE or some other way to remove the overhead?


behdad
http://behdad.org/

Re: CFF loading overhead in tracing

[Behdad Esfahbod]

Humm. I cannot reproduce this anymore. Will report if that changes.

behdad
http://behdad.org/


On Sun, Jul 30, 2023 at 12:41 PM Behdad Esfahbod  wrote:

> Hi,
>
> In benchmarking FreeType face loading, I noticed that the following two
> loops take considerable time when loading CFF1 face:
>
>
> --- a/src/cff/cffobjs.c
> +++ b/src/cff/cffobjs.c
> @@ -695,8 +695,8 @@
>
>
>FT_TRACE4(( "  %5d ", idx + 390 ));
> -  for ( l = 0; l < s1len; l++ )
> -FT_TRACE4(( "%c", s1[l] ));
> +  //for ( l = 0; l < s1len; l++ )
> +//FT_TRACE4(( "%c", s1[l] ));
>FT_TRACE4(( "\n" ));
>  }
>
> @@ -710,8 +710,8 @@
>
>
>FT_TRACE4(( "  %5d ", cff->num_strings + 390 ));
> -  for ( l = 0; l < s1len; l++ )
> -FT_TRACE4(( "%c", s1[l] ));
> +  //for ( l = 0; l < s1len; l++ )
> +//FT_TRACE4(( "%c", s1[l] ));
>FT_TRACE4(( "\n" ));
>  }
>}
>
>
> I don't have tracing enabled, but the compiler doesn't seem to have wiped
> away the loop. I'm not sure why. At any rate, I wonder if these can be
> guarded by FT_DEBUG_TRACE or some other way to remove the overhead?
>
>
> behdad
> http://behdad.org/
>

Re: GSoC 2023

[Behdad Esfahbod]

I apologize. I forgot about ftbench.

behdad
http://behdad.org/


On Fri, Feb 3, 2023 at 9:22 AM Behdad Esfahbod  wrote:

> Hi Werner,
>
> One idea would be to develop a performance benchmarking suite of various
> aspects of the library's functionality. I don't think FreeType currently
> has one?
>
> For ideas, you can look look at HarfBuzz's here (which also measure's
> FreeType):
>
>   https://github.com/harfbuzz/harfbuzz/tree/main/perf
>
> We use google-benchmark library (C++) for this and have been very happy
> with it.
>
> Regards,
>
> behdad
> http://behdad.org/
>
>
> On Fri, Feb 3, 2023 at 12:12 AM Werner LEMBERG  wrote:
>
>>
>> Folks,
>>
>>
>> I've just applied to GSoC 2023.  Let's see whether we will be accepted
>> this year.  I've also updated our GSoC pages at
>> https://freetype.org/gsoc.html – if you have ideas for improvements or
>> new projects, please write to this list!
>>
>>
>> Werner
>>
>

HarfBuzz now renders COLRv1

[Behdad Esfahbod]

Hi,

HarfBuzz now renders COLRv1, in two ways:

  1. a native implementation,

  2. using the FreeType API.

For the latter, we found a couple of issues that I like to report:

  - In using FT_Get_Paint_Layers(), I found that I need to initialize the
out-parameter FT_OpaquePaint to zero, otherwise the API won't work. I
confirmed this in the code, yet this seems undocumented,

  - In our implementation we need to access color-stops starting at
arbitrary offset. Currently looks like the iterator
in FT_Get_Colorline_Stops() does not allow that, so we have to iterate from
the beginning every time. We also have to reset the iterator so we can
iterate it multiple times.

Regards,

behdad
http://behdad.org/

Re: FT_Get_Advance() too slow?

[Behdad Esfahbod]

Hi Werner,

Regarding this thread:

https://lists.nongnu.org/archive/html/freetype-devel/2022-05/msg4.html

I finally spent enough time on it to have a clue. I wrote up my findings in
a document:

https://docs.google.com/document/d/1wskYbA-czBt57oH9gEuGf3sWbTx7bfOiEIcDs36-heo

The short answer is that basically fetching advances from hmtx is such a
small bit of work, that HarfBuzz does it in just a few operations because
of inlining, but all the function call and other overheads in FreeType add
up...

hb-ft is also not asking FreeType for NO_SCALE where it, in theory, can.
That's contributing to this as well, but only 10%.

Regards,

behdad
http://behdad.org/

Re: FT_Get_Advance() too slow?

[Behdad Esfahbod]

Hi Werner,

Any chance the one-line patch below can be applied?

Thanks,

behdad
http://behdad.org/


On Fri, May 20, 2022 at 11:05 AM Behdad Esfahbod  wrote:

> Hi,
>
> I'm debugging an issue where FT_Get_Advance(), even in its fast path
> (NO_HINTING), seems to be much slower than the equivalent HarfBuzz code.
> Much of it seems to be overhead because we have to call FT_Get_Advance()
> one glyph at a time and it does multiple indirections before getting the
> advance and returning.
>
> But I also found that it tries to apply variations unconditionally. The
> following patch fixes that to only try applying variations if the font has
> blends set. For me this seems to help a bit (~20% of my numbers):
>
> diff --git a/src/sfnt/ttmtx.c b/src/sfnt/ttmtx.c
> index 7aece36fb..5bca8560d 100644
> --- a/src/sfnt/ttmtx.c
> +++ b/src/sfnt/ttmtx.c
> @@ -306,7 +306,7 @@
>  }
>
>  #ifdef TT_CONFIG_OPTION_GX_VAR_SUPPORT
> -if ( var )
> +if ( var && face->blend )
>  {
>FT_Face  f = FT_FACE( face );
>FT_Int   a = (FT_Int)*aadvance;
>
> For the curious, I'm using perf/benchmark-font in the harfbuzz repo.
> Here's the numbers of interest:
>
> $ ninja -Cbuild && LD_PRELOAD=~/freetype/objs/.libs/libfreetype.so
> build/perf/benchmark-font --benchmark_filter=advance --benchmark_out=after
> ninja: Entering directory `build'
> ninja: no work to do.
> 2022-05-20T11:01:01-06:00
> Running build/perf/benchmark-font
> Run on (24 X 3665.32 MHz CPU s)
> CPU Caches:
>   L1 Data 32 KiB (x12)
>   L1 Instruction 32 KiB (x12)
>   L2 Unified 512 KiB (x12)
>   L3 Unified 32768 KiB (x2)
> Load Average: 0.28, 0.80, 1.02
>
> 
> Benchmark
>  Time CPU   Iterations
>
> 
> BM_Font/glyph_h_advances/Roboto-Regular.ttf/hb  3.08
> us 3.08 us   227980
> BM_Font/glyph_h_advances/Roboto-Regular.ttf/ft  18.5
> us 18.5 us37889
> BM_Font/glyph_h_advances/Roboto-Regular.ttf/var/hb  3.09
> us 3.08 us   226996
> BM_Font/glyph_h_advances/Roboto-Regular.ttf/var/ft  18.3
> us 18.2 us38431
> BM_Font/glyph_h_advances/SourceSansPro-Regular.otf/hb   4.62
> us 4.61 us   150940
> BM_Font/glyph_h_advances/SourceSansPro-Regular.otf/ft   27.4
> us 27.3 us25622
> BM_Font/glyph_h_advances/AdobeVFPrototype.otf/hb   0.752
> us0.751 us   932022
> BM_Font/glyph_h_advances/AdobeVFPrototype.otf/ft1.83
> us 1.83 us   380586
> BM_Font/glyph_h_advances/AdobeVFPrototype.otf/var/hb6.22
> us 6.21 us   112788
> BM_Font/glyph_h_advances/AdobeVFPrototype.otf/var/ft3.53
> us 3.52 us   199363
> BM_Font/glyph_h_advances/SourceSerifVariable-Roman.ttf/hb   3.41
> us 3.40 us   205771
> BM_Font/glyph_h_advances/SourceSerifVariable-Roman.ttf/ft   20.2
> us 20.2 us34728
> BM_Font/glyph_h_advances/SourceSerifVariable-Roman.ttf/var/hb   28.3
> us 28.2 us24723
> BM_Font/glyph_h_advances/SourceSerifVariable-Roman.ttf/var/ft   37.0
> us 36.9 us18952
> BM_Font/glyph_h_advances/Comfortaa-Regular-new.ttf/hb   2.08
> us 2.08 us   336868
> BM_Font/glyph_h_advances/Comfortaa-Regular-new.ttf/ft   12.2
> us 12.2 us56816
> BM_Font/glyph_h_advances/NotoNastaliqUrdu-Regular.ttf/hb3.24
> us 3.24 us   216425
> BM_Font/glyph_h_advances/NotoNastaliqUrdu-Regular.ttf/ft19.2
> us 19.2 us36445
> BM_Font/glyph_h_advances/NotoSerifMyanmar-Regular.otf/hb1.67
> us 1.67 us   418787
> BM_Font/glyph_h_advances/NotoSerifMyanmar-Regular.otf/ft9.92
> us 9.90 us70415
>
> I truly cannot explain the order-of-magnitude difference so far.
>
> Regards,
> behdad
> http://behdad.org/
>

FT_Get_Advance() too slow?

[Behdad Esfahbod]

Hi,

I'm debugging an issue where FT_Get_Advance(), even in its fast path
(NO_HINTING), seems to be much slower than the equivalent HarfBuzz code.
Much of it seems to be overhead because we have to call FT_Get_Advance()
one glyph at a time and it does multiple indirections before getting the
advance and returning.

But I also found that it tries to apply variations unconditionally. The
following patch fixes that to only try applying variations if the font has
blends set. For me this seems to help a bit (~20% of my numbers):

diff --git a/src/sfnt/ttmtx.c b/src/sfnt/ttmtx.c
index 7aece36fb..5bca8560d 100644
--- a/src/sfnt/ttmtx.c
+++ b/src/sfnt/ttmtx.c
@@ -306,7 +306,7 @@
 }

 #ifdef TT_CONFIG_OPTION_GX_VAR_SUPPORT
-if ( var )
+if ( var && face->blend )
 {
   FT_Face  f = FT_FACE( face );
   FT_Int   a = (FT_Int)*aadvance;

For the curious, I'm using perf/benchmark-font in the harfbuzz repo. Here's
the numbers of interest:

$ ninja -Cbuild && LD_PRELOAD=~/freetype/objs/.libs/libfreetype.so
build/perf/benchmark-font --benchmark_filter=advance --benchmark_out=after
ninja: Entering directory `build'
ninja: no work to do.
2022-05-20T11:01:01-06:00
Running build/perf/benchmark-font
Run on (24 X 3665.32 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x12)
  L1 Instruction 32 KiB (x12)
  L2 Unified 512 KiB (x12)
  L3 Unified 32768 KiB (x2)
Load Average: 0.28, 0.80, 1.02

Benchmark  Time
CPU   Iterations

BM_Font/glyph_h_advances/Roboto-Regular.ttf/hb  3.08 us
3.08 us   227980
BM_Font/glyph_h_advances/Roboto-Regular.ttf/ft  18.5 us
18.5 us37889
BM_Font/glyph_h_advances/Roboto-Regular.ttf/var/hb  3.09 us
3.08 us   226996
BM_Font/glyph_h_advances/Roboto-Regular.ttf/var/ft  18.3 us
18.2 us38431
BM_Font/glyph_h_advances/SourceSansPro-Regular.otf/hb   4.62 us
4.61 us   150940
BM_Font/glyph_h_advances/SourceSansPro-Regular.otf/ft   27.4 us
27.3 us25622
BM_Font/glyph_h_advances/AdobeVFPrototype.otf/hb   0.752 us
   0.751 us   932022
BM_Font/glyph_h_advances/AdobeVFPrototype.otf/ft1.83 us
1.83 us   380586
BM_Font/glyph_h_advances/AdobeVFPrototype.otf/var/hb6.22 us
6.21 us   112788
BM_Font/glyph_h_advances/AdobeVFPrototype.otf/var/ft3.53 us
3.52 us   199363
BM_Font/glyph_h_advances/SourceSerifVariable-Roman.ttf/hb   3.41 us
3.40 us   205771
BM_Font/glyph_h_advances/SourceSerifVariable-Roman.ttf/ft   20.2 us
20.2 us34728
BM_Font/glyph_h_advances/SourceSerifVariable-Roman.ttf/var/hb   28.3 us
28.2 us24723
BM_Font/glyph_h_advances/SourceSerifVariable-Roman.ttf/var/ft   37.0 us
36.9 us18952
BM_Font/glyph_h_advances/Comfortaa-Regular-new.ttf/hb   2.08 us
2.08 us   336868
BM_Font/glyph_h_advances/Comfortaa-Regular-new.ttf/ft   12.2 us
12.2 us56816
BM_Font/glyph_h_advances/NotoNastaliqUrdu-Regular.ttf/hb3.24 us
3.24 us   216425
BM_Font/glyph_h_advances/NotoNastaliqUrdu-Regular.ttf/ft19.2 us
19.2 us36445
BM_Font/glyph_h_advances/NotoSerifMyanmar-Regular.otf/hb1.67 us
1.67 us   418787
BM_Font/glyph_h_advances/NotoSerifMyanmar-Regular.otf/ft9.92 us
9.90 us70415

I truly cannot explain the order-of-magnitude difference so far.

Regards,
behdad
http://behdad.org/

Re: [ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

[Behdad Esfahbod]

On Sat, Aug 29, 2020 at 9:12 PM Anuj Verma  wrote:

> Hello All,
>
> I have written the final report for my project.
>
> You can check it out here:
> https://gitlab.com/-/snippets/2007070
>

Thank you Anuj. I really enjoyed observing your work this summer, even
though I didn't get to contribute more review. I promised you a proof and
here it is:

> Lemma: if the closest point on curve [0,1] is to the endpoint at t=1 and
the cubic equation has no real root at t=1, the cubic equation must have at
least one real root at some t > 1.
> Similarly, if the closest point on curve [0,1] is to the endpoint at t=0
and the cubic equation has no real root at t=0, the cubic equation must
have at least one real root at some t < 0.
>
> As such, you just need to compute all real roots, clamp them to [0,1] and
remove duplicates.

Here's the proof for the first case: Consider the derivative of the
distance, called "the function" from here on. It's a continuous function.
At t=1 the function is a negative number because of the assumptions. When t
tends towards +infinity, the function approaches +infinity. As such, there
exist t > 1 where the function is zero.

Cheers,
b

Re: mmap and Windows

[Behdad Esfahbod]

Here's how HarfBuzz does it:

 https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-blob.cc

On Sat, Aug 29, 2020, 10:33 AM Vincent Torri 
wrote:

> On Sat, Aug 29, 2020 at 11:52 AM Werner LEMBERG  wrote:
> >
> >
> > >> If this really makes a difference on Windows, and if you want to
> > >> contribute such code, you are welcome to do so!
> > >
> > > I guess that mmap is useful with a font with a large size, right ?
> > > if so, do you have a font to test with ?
> >
> > You want a very large font to play around?  I suggest to try
> > `NotoSansCJK.ttc`, which is a 100MByte font:
> >
> >
> https://github.com/googlefonts/noto-cjk/blob/master/NotoSansCJK.ttc.zip
>
> thank you
>
> should I write a builds/win32/ftsystem.c ?
>
> Vincent Torri
>
>

Re: I'm back

[Behdad Esfahbod]

Hi David,

Thanks for the detailed response.

On Mon, Jun 29, 2020 at 5:07 PM David Turner  wrote:

>
>
> Le dim. 28 juin 2020 à 04:19, Behdad Esfahbod  a
> écrit :
>
>> Hi David,
>>
>> I've been meaning to reply to your request but the list of things I
>> wanted to communicate kept growing exponentially and so I have not been
>> able to say.
>>
>> But here, from a technical perspective this is my biggest issue, which
>> you can also see as a roadmap:
>>
>>   https://gitlab.gnome.org/GNOME/pango/-/issues/404#note_851881
>>
>>
> Thanks for the link Bhedad, this gives useful history about your woes and
> considerations. I'd like to address some of these here.
>
> First of all, the reason why FreeType has never been designed to be
> "thread-safe" (in the sense where it supports multiple threads operating on
> its objects concurrently [1]) is *entirely and very very intentional*.
>

I fully understand it was intentional.


> The library was designed, first and foremost to be as efficient as
> possible on embedded systems with limited memory and operating system
> primitives.
> Any kind of thread-safety scheme, even atomic refcounts, would have been
> detrimental to its portability, and most likely performance.
>

But that doesn't have to be the case. For example, HarfBuzz could always be
compiled with HB_NO_MT to remove all that overhead. See hb-atomic.hh We
even enable that in our HB_TINY configuration. See CONFIG.md and
hb-config.hh.


> Reducing memory usage means using in-place modification of existing
> objects and aggressive caching of state within various objects under a root
> FT_Library instance.
>

I'm not convinced that you lose *any* efficiency within the model that I
propose. I hold HarfBuzz to the same if not more extreme standards and we
have pretty much always been able to find a solution without compromising.
We continue to do that. In fact, last night I started a major overhaul of
the codebase.

That's why we have FT_Size and FT_GlyphSlot objects, very visible in the
> API, but there are also various levels of caching internally (most of them
> simple LRU lists that only change occasionally, but still a potential
> source of thread races).
>

Umm. I removed all of those a few years ago. Again, without any side effect.


> And as far as I know, this has always been pointed out explicitly in the
> FT_Library documentation.
>

Yeah I'm not claiming any of it is a surprise (there was one surprise I ran
into the other day that I'll write about separately).


> I understand that if you expected otherwise, you may have been
> disappointed (to keep it politely).
>

I came to this field with zero expectations. Everything I learned was from
how people in projects large and small needed to show text.


> However I do not consider the API to be "broken" regarding thread-safety,
> it's just not designed for this use case, at all. It solves a very
> different problem.
>

If you wish so. I'm not crazy about words. :-)


> Thus there is no way to "fix all thread-safety" issues in it, without
> changing the internals and the API tremendously.
>

Agree about the internals, but not the API. I think new API can be added
and old API kept. It will be a complete overhaul, I agree, but then again,
the project is way overdue for one. So I'm suggesting that instead of a
freetype3 that has incompatible ABI, just evolve freetype2 into freetype3,
and freetype4, ... and remove old cruft after ten years or twenty years or
never. That's what I'm leaving HarfBuzz with.

You may have made some modifications to the library to get rid of the most
> annoying thread-related issues you've encountered,
> but I assure you there are still by-design thread-races in many places.
> Also, some of the fixes seem a little dubious, i.e. the raster pool is now
> a fixed 16 kiB now, while it used to be resizable by the user.
>

In twenty years I never ran into *any* FreeType client who would get
anywhere like configuring anything like that. If they did, they'd just
modify the source.

Again, I understand everything I point out can be countered with a "some
might need". That's a difference in library design philosophy.


> This was useful when rendering large vector graphics (not fonts) with the
> FreeType rasterizers. Now the algorithm are essentially quadratic, which
> makes it painful or unusable for this use case.
>

Again, if there was a mission statement to FreeType, we could deduce
whether that should remain a goal.


> The root of your problem seems to be a vast impedance mismatch between the
> Cairo / Pango / Harfbuzz APIs which expect, or encourage, several threads
> (probably from clients, which would be worse) to use FT_Face objects
> liberally.
> This simp

Re: I'm back

[Behdad Esfahbod]

Hi David,

I've been meaning to reply to your request but the list of things I wanted
to communicate kept growing exponentially and so I have not been able to
say.

But here, from a technical perspective this is my biggest issue, which you
can also see as a roadmap:

  https://gitlab.gnome.org/GNOME/pango/-/issues/404#note_851881

I will keep trying to comment on the two GSoC projects, and eventually get
to write about the health of the freetype as a community project.

Cheers,
behdad

On Fri, Apr 24, 2020 at 1:03 PM David Turner  wrote:

> Hello freetype-devel@ list members,
>
> It's been a very very long time, but I have some free time in the coming
> weeks to work on FreeType. Werner invited me to write a small announcement
> here and I'm currently looking at the official bugs list.
>
> I'd like to know what are, in your opinion, the most pressing issues to
> work on at that point?
>
> Apart from that, I had the following things in mind:
>
> - Improving / refactoring the build system a little. E.g. it should be
> possible to simplify the rules.mk/module.mk files considerably, and
> auto-generate most of the Makefiles / Jamfiles / CMakefiles from a single
> source of truth (exact format to be defined), at least the parts that deal
> with the headers / sources / configuration headers and the module
> dependencies.
>
> - Improve testing (unit and regression tests to be exact) There are lots
> of possibilities here, and it will probably better to do this in small
> incremental steps.
>
> Voila, I'd be happy to read your suggestions, Happy to be here.
>
> - David Turner
>


-- 
behdad
http://behdad.org/

Re: Logging Library-GSOC

[Behdad Esfahbod]

On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG  wrote:

>
> > I find it a *very* bad idea to have code in FreeType that would
> > write to a file.  Specially bad if that can be controlled by an
> > env-var.
>
> Interesting.  Please explain.  Do you fear security issues?
>

Sorry, forgot to reply to this.  Yes, security.  I give you a couple of
examples:

  - On a security-sensitive system, even an extra open file handle is an
extra tool an attacker can use to mount their attack.  Read this epic story:

https://threatpost.com/pinkiepie-strikes-again-compromises-google-chrome-pwnium-contest-hack-box-101012/77098/
https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html
https://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html

  - A few years ago there was an attempted attack on ChromeOS.  Some
ChromeOS UI components were using GTK+, which uses Pango.  Pango used to
have a config file.  The default search path for the config file looked in
certain directories on the user's home-directory, which is writable to the
user.  It could also be controlled via an environment variable.  The config
file could reconfigure where Pango module map was loaded from.  The Pango
module map pointed to binary modules to load for shaping certain scripts.
Pango would dlopen() such modules and look for a specifically named symbols
and call those.  That's already problematic, because it means that an
attacker who finds a way to write files to user's home directory would be
able to make the system UI load custom code.  On top of that, note that
that on Linux / ELF as well as most other systems, binary modules can
execute code at runtime linking stage.  That means, such attack could run
arbitrary code on processes that just linked to GTK+ and initialized it but
not even display any text.

So when I hear about a system, no matter what it is, that will write to
file, controlled via env-vars, and configured through a config file, my
immediate response is:

  - That sounds like hell of a lot of security vectors, for...
  - A feature that is not even justified to begin with!  FreeType clients
what to read text.  None of this contributes to any of that.

While you may be tempted to argue why it won't be a problem for FreeType
(for example because it will be disabled by default), I accept that.  But
that is in conflict with what Armin's stance is on this.  I'll expand in
the other thread.  I'm still hopeful to be able to write that today.

Re: Logging Library-GSOC

[Behdad Esfahbod]

On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG  wrote:

>
> > I find it a *very* bad idea to have code in FreeType that would
> > write to a file.  Specially bad if that can be controlled by an
> > env-var.
>
> Interesting.  Please explain.  Do you fear security issues?
>
> > I still think what's desired can be done best by just revamping and
> > writing custom code in FreeType itself.
>
> Yes, this is another possibility.  We haven't yet decided how to
> proceed; Priyesh is still in the investigation phase.


Those words are not consistent with your actions.  I'll reply in other
thread I specifically started about this topic earlier.

-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

Hi Anuj,

On Tue, Jun 16, 2020 at 9:43 PM Anuj Verma  wrote:

> Hello Behdad,
>
> > First, let me congratulate you.  This is a very thorough and impressive
> piece of work for such a short time period.
>
> Thank you for that. Viktor's paper did help me a lot while writing the
> code. I guess you have already read his paper,
> but in case anyone is interested in reading it check this out:
> https://github.com/Chlumsky/msdfgen. It contains all
> the relevant information for generating SDF from outlines. Although I'm
> not using the full potential of the paper currently.
>

I have.  In 2018 Nicolas Rougier and I presented a mini-course at SIGGRAPH
that covered all the SDF-based experiments of the past 10 / 15 years.  If
you haven't reviewed those, I suggest you do.  Unfortunately there's no
video and the slides are low resolution:


https://www.slideshare.net/NicolasRougier1/siggraph-2018-digital-typography

In particular, I advise that you read the 2018-Langyel paper, which is
what's in sluglibrary.com:

  http://www.terathon.com/i3d2018_lengyel.pdf

Because if you follow my line of reasoning in my previous messages and the
rest of this message, I'm advising that you implement what basically will
be Lengyel's algorithm on the CPU.


> - I highly suggest you stick to float internally [...]
>
> I still think `float' is a better option for generating SDF, especially in
> lower resolution glyphs where fixed-point produces
> kind of straight lines instead of smooth curves(which is not noticable if
> you look at it briefly). But my concern is that
> FreeType doesn't use floats at the moment and I don't think it will be a
> good idea to add support for floats just for the
> sake of this project.
> It's a tradeoff between one thing or the other and I can't decide which
> would be the best considering the current state of
> library. I would say that I'm inclined on using fixed-point integers just
> because FreeType doesn't use them.
> Also, why doesn't FreeType use floats? Is it just because of platform
> which doesn't have floating point type? or are there
> more reasons? This question has been in my mind for quite some time.
>

I addressed that in my reply to Werner a few minutes ago.



> > Have you measured performance?  I'm fairly sure the float can be made
> both more robust and faster.
>
> I just did, here are the results with compiler optimization turned on
> using chrono library:
>
> A) Line Segment: ~0.026 microseconds
> B) Conic Bezier: ~0.168 microseconds
> C) Cubic Bezier: ~0.469 microseconds
>
> [I have also attached the gprof output in case you are interested. Note
> that the gprof output is without any compiler optimization]
> To compare it to fixed-point check here:
> https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00095.html
>

So basically you already showed that using fixed is slower and introduces
artifacts.  To me that was unnecessary as both were very well-understood to
anyone who has worked in this field.  But now that you have, I strongly
advise you stick to float.


> - Your Newton-Raphson is solid and your performance numbers look
> amazing.  I think you should stick with this approach instead of
> subdividing.
> > As was suggested by others, do experiment with Raphson on your quadratic
> as well.
>
> Yes, will try to use Raphson on quadratic, although I don't think it will
> be better than solving the cubic equation. And I will stick to it
> until I find something even faster.
>

I take that back for now.  It might be workable, but stick with what you
have.  We can find other ways to make your cubic-solving faster.  More
about my position-reversal on Raphson below.



> > * Currently you abandon as soon as factor falls outside of [0,1].
> That's wrong.  Factor might go out but come back in in the next iteration.
>
> I was doing that initially, but I saw that the factor goes `out' and when
> it come back `in' it has the same value as the previous `in' value.
> This causes 2 extra passes of a fairly expensive iteration, so I decided
> to break if it goes outside the range. But, yeah I will see if
> that is wrong and decide accordingly after further testing.
>

I thought about that a lot and did some research.  This is a good summary:


https://math.stackexchange.com/questions/2432348/what-is-stopping-criteria-for-newtons-method/2433475#2433475

Basically, if the solution is pulled out of [0,1] range, you can clamp
them.  If they keep pulling out again right after clamping, you can
discard.  That post also suggests that what you are seeing was caused by
your fixed-point limitations.  Were you testing with float or fixed?  This
is the part I'm referring to:
  "Occasionally, it is helpful to remember that Newton's method exhibits
one sided convergence in the limit, i.e. if the root is a simple, then the
residuals 푓(푥푛)f(xn) eventually have the same sign. Deviation from this
behavior indicates that you are pushing against the limitations imposed by
floating point arithmetic."

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

Werner!

On Wed, Jun 17, 2020 at 12:23 AM Werner LEMBERG  wrote:

> > Also, why doesn't FreeType use floats?  Is it just because of
> > platform which doesn't have floating point type?
>
> Yes.  The original intention of FreeType was to provide support for
> embedded devices, which usually are systems that have CPUs with very
> limited capabilities and a tiny amount of memory.  This goal hasn't
>

Reminds me of Colbert on Bush: "The greatest thing about this man is that
he’s steady. You know where he stands,” Colbert said about Bush. “He
believes the same thing Wednesday that he believed on Monday — no matter
what happened Tuesday.  Events can change; this man’s beliefs never will."

FreeType was designed in the 90s.  Back then there were embedded systems
that did not have an FPU.  There also existed embedded systems that did not
allow a library to have static writable data segment.  Both of those
limitations were ingrained into FreeType design.  Both are *still* actively
defended.  In the meantime the world has changed...

Systems without an FPU are vastly less common than they were 20 years ago.
They still exist, and is a defendable position to want FreeType to continue
to work on those systems, however:

  - Compilers and kernels have stepped up to provide floating-point
emulation libraries which work transparently to the client code.  That is,
introducing limited use of float in FreeType is by no means an impediment
to those building the library for systems without FPU.  Even if that was
not true, the SDF module can be easily disabled,

  - I have a *very* hard time imagining any system that has a programmable
GPU, but no FPU.  As such, I find it completely nonsensical to ban using
float for the SDF generation.

In HarfBuzz we started from the same position, exactly because of precedent
in FreeType.  But when we got to variable fonts, we acknowledged the shift
in the scene and just used float internally.  Broke nothing... And sure
there are users of FreeType who won't ever want HarfBuzz.  I'm not ruling
those use-cases out categorically.  But my arguments above address those
situations as well.

I strongly advise that you reconsider this.  And many other decisions that
seem to be stuck in 20 years ago.  I'm working on writing a full assessment
of FreeType as a project and will share in a new thread when that is
ready.  In the meantime, I like to see Anuj's time be spent in producing a
**solid** SDF implementation, instead of fighting barriers that are not
technically justified.

b



-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

On Tue, Jun 16, 2020 at 9:54 PM Anuj Verma  wrote:

>
> > Also I'm surprised that you haven't put the code get_min_distance code
> for each edge type into a function.
> > Would you prefer that I comment re these on github?
>
> I don't think that will be necessary. I will fix that while adding in
> FreeType. That repository is just for
> testing and I might delete it in the future.
>

I understand.  I find it using functions generously makes one's code
develop and flow better.  In this case I wanted to quickly test your
Newton-Raphson in isolation.  Sure, I know how to isolate it. :)

-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

On Wed, Jun 17, 2020 at 7:22 PM Alexei Podtelezhnikov 
wrote:

> Hi Anuj,
>
> Please let me finish my thoughts below...
>
> >> Each curved segment has a large number of neighboring grid points.
> >> each of which has a unique nearest projection on the curve. The curve
> >> is naturally sampled by these projection points a very large number of
> >> times and quite uniformly. Therefore, why not divide the curve into a
> >> large number of  segments to begin with and then just find whatever
> >> point is close to each grid? It could be a lot faster to find the
> >> distance this way.
>
> ...
> It is at this point I am asking why not just split the curve using De
> Casteljau's algorithm recursively a large number of times and
> calculate the distance field for a slightly jagged line to begin with.
>

Because then instead of one curve you have tens of tiny lines to walk
over.  The speed doesn't work.


> The distance field will do the magic regardless and thread the
> boundary smoothly through the grid...
>
> On Wed, Jun 17, 2020 at 1:08 AM Anuj Verma  wrote:
> > I guess this is similar to the Euclidean distance transform algorithm.
> > http://webstaff.itn.liu.se/~stegu/JFA/Danielsson.pdf
>
> No, I do not think this is it.
>
> > As I said before I will not leave out this option, I will try to
> implement this
> > and then we can compare the performance.
> [skip]
> > I don't find anything offending in your suggestions.
>
> ;)
>
>

-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

On Tue, Jun 16, 2020 at 11:02 AM Werner LEMBERG  wrote:

>
> > For SIMD, I studied what's available last year for HarfBuzz.  I
> > documented what I found here:
> >
> >   https://github.com/harfbuzz/harfbuzz/blob/simd/src/hb-simd.hh
>
> Thanks for the link, it's an interesting read.
>
> > If you use floats internally and fill in the distances, then you can
> > do SIMD passes at the end to do sqrt, clamping, and other things to
> > generate the output.  But even solving computing roots or the
> > Newton-Raphson can be done in SIMD for up to 8 samples at a time.
>
> IMHO, in FreeType, SIMD support is something to be done in addition,
> not as a replacement.


Absolutely.  It's implied and I agree that we must support non-SIMD.  All
projects I know have the same requirements.


>   Since Anuj makes quick progress I suggest that
> he first concentrates on the fixed-float route.  If there is some time
> left we should check how to SIMD can be implemented.
>

Agreed.  I pointed out in case it can inform how to organize the operations
such that SIMD benefit can be achieved later.  I think such organization
also produces faster code without SIMD.  Eg. doing a tight loop of just
sqrt()ing every pixel in the end allows the compiler to unroll the loop,
which also enables better use of the multiple pipelines in the CPU because
there's no data dependency.

-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

For SIMD, I studied what's available last year for HarfBuzz.  I documented
what I found here:

  https://github.com/harfbuzz/harfbuzz/blob/simd/src/hb-simd.hh

If you use floats internally and fill in the distances, then you can do
SIMD passes at the end to do sqrt, clamping, and other things to generate
the output.  But even solving computing roots or the Newton-Raphson can be
done in SIMD for up to 8 samples at a time.

On Tue, Jun 16, 2020 at 8:51 AM Behdad Esfahbod  wrote:

> Hi Anuj,
>
> First, let me congratulate you.  This is a very thorough and impressive
> piece of work for such a short time period.  I read your code over a week
> ago but couldn't sit down and type this.  I see there has been lots of
> progress since.  I'll just summarize:
>
> - I highly suggest you stick to float internally.  Any fixed-point and you
> will inevitably hit rasterization issues no matter how hard you try.  This
> is a tried and tested failure path and I encourage you to stay away from
> it.  I see you did the fixed already.  Have you measured performance?  I'm
> fairly sure the float can be made both more robust and faster.  Specially,
> when and if going for SIMD, you get inverse-sqrt for float but not int and
> that seems to be the slowest part of your work, which is normalizing
> vectors.  And I agree, you should do everything in squared-distance, then
> do a full pass over the results and do the (SIMD if available) sqrt()ing.
> I believe you still need normalizing vectors though.
>
> - Your Newton-Raphson is solid and your performance numbers look amazing.
> I think you should stick with this approach instead of subdividing.  As was
> suggested by others, do experiment with Raphson on your quadratic as well.
> A couple things there:
>
>   * Currently you abandon as soon as factor falls outside of [0,1].
> That's wrong.  Factor might go out but come back in in the next iteration.
>
>   * I've convinced myself, but probably can't be proved, that MAX_DIVISIONS=2
> is enough for always finding the closest point. That would speed up
> significantly.
>
> - Your quadratic code always adds t=0 and t=1 as roots. You don't need to.
> Only clamp the real roots to [0,1] range and remove duplicates.
>
> - Your handling of two edges meeting at a corner is solid. That's exactly
> what we do in GLyphy. However, I'm also now convinced that there is no way
> to produce SDF from contours that might overlap. Imagine a "+" sign that is
> two straight contours. You cannot find the distance around the
> intersection. That's really bad news :(. Removing overlaps is extremely
> tricky and so far we've stayed away from adding to FreeType. SkiaPathOps
> seems to be the most solid Open Source implementation. I don't have any
> suggestion as to how to proceed. I can only say do your work without
> overlaps and document that as a caveat. I'm sorry I told you you need to do
> winding tracking. That would help for other reasons, ie. when you have two
> clockwise circles inside each other and a counter-clockwise one inside
> those. The middle should be black. To get that black you need to count
> winding of a ray from point to infinity. That's not what you are doing.
> Again, okay to initially document that shortcoming.
>
> - I still think an option to get A8 output is desired, since that's enough
> for a respectable rendering in most situations and is 50% more efficient
> than a 16-bit. Also, most GPU hardware doesn't support 16-bit textures.
>
> - There was one place when I checked last week, that you were computing
> distance then squaring it instead of just getting the squared_distance for
> which you already had a function.
>
> - Your "spread" stuff. Spread is good, and user sets that depends on 1.
> the width of filter they gonna use for rasterizing, 2. minimum size they
> want to rasterize at. What that means is:
>
> * x_pad / y_pad should be set equal to spread,
>
> * The final normalizing you are doing based on max-distance is
> nonsensical. Makes the SDF unusable for rasterization.
>
> Re different filters, I found that they don't really matter. You can see
> my results in my slides / video:
>
> http://behdad.org/glyphy_slides.pdf
> https://vimeo.com/83732058
>
> That's all I remember.  I'll look into your latest code at some point.
>
> Regards,
> behdad
>
> On Sat, Jun 6, 2020 at 9:51 PM Anuj Verma  wrote:
>
>> Hello All,
>>
>>
>> *> Have you figured out FT_Fixed arithmetic? You still use floats in your
>> > code. I think you should convert to FT_Fixed first. *
>>
>> So, I have been trying to convert my code to FT_Fixed for a few days now
>> without any success.
>> I did manage to use fixed point for shapes with only

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

On Tue, Jun 16, 2020 at 9:49 AM Alexei Podtelezhnikov 
wrote:

> Anuj,
>
> Each curved segment has a large number of neighboring grid points.
> each of which has a unique nearest projection on the curve. The curve
> is naturally sampled by this projection points a very large number of
> times and quite uniformly. Therefore, why not divide the curve into a
> large number of  segments to begin with and then just find whatever
> point is close to each grid? It could be a lot faster to find the
> distance this way.
>

So... You subdivide the curves into lines.  Can you sketch what you do then?

I did think about "rasterizing" the outline and mark all pixels that have
distance < 1.0 to the outline, and then "propagate" the distance out.  But
as I've shown in my GLyphy talk, no matter how much I thought about this, I
found that there can be points far from the curve such that the closest
edge for this point is different from the closest edge for all its
neighboring pixels.  As such, the only way to use this optimization is if
each pixel kept a list of edges that are closest, within a range  That
then suggests that just using a coarse grid is even better, hence what I
suggested.

-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

On Tue, Jun 16, 2020 at 9:50 AM Werner LEMBERG  wrote:

> >>> - Your handling of two edges meeting at a corner is solid.  That's
> >>>   exactly what we do in GLyphy.  However, I'm also now convinced
> >>>   that there is no way to produce SDF from contours that might
> >>>   overlap.  Imagine a "+" sign that is two straight contours.  You
> >>>   cannot find the distance around the intersection.  That's really
> >>>   bad news :(.  Removing overlaps is extremely tricky and so far
> >>>   we've stayed away from adding to FreeType.
>
> This is an interesting idea.  I'm very open to add an API for removing
> overlaps.
>
> >>> SkiaPathOps seems to be the most solid Open Source implementation.
>
> URL, please.  A quick search on Google only shows video results.
>

Watch this video first so you appreciate the level of finesse that has gone
into it:

  https://www.youtube.com/watch?v=OmfliNQsk88

The code is part of Skia.  In FontTools we needed that so Cosimo & others
wrapped that into Python:

  https://github.com/fonttools/skia-pathops

SkiaPathOps can be compiled separately from the rest of Skia.  That was by
design.  When we started using this for font production, we hit a couple of
problems. If I remember correctly, it didn't necessarily retain the
direction of contours.  Ie. it worked for even-odd only.  They were open to
addressing those issues so it can be used for font production.  And I know
fontmake pipeline uses it now.  I've CC'ed Cosimo & Ben who can comment.

And yes, that library removes overlaps on curves directly.

b


> >>> I don't have any suggestion as to how to proceed.  I can only say
> >>> do your work without overlaps and document that as a caveat.
>
> Sounds like a good suggestion.
>
>
> Werner
>


-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

Also I'm surprised that you haven't put the code get_min_distance code for
each edge type into a function.  Would you prefer that I comment re these
on github?

On Tue, Jun 16, 2020 at 8:53 AM Behdad Esfahbod  wrote:

> Oh, I forgot:
>
> After you do all this, you will realize that the speed is still a
> concern.  Don't do bounding-box check.  Classic way to do after is to split
> into a coarse grid and for each cell find all edges that may be relevant.
> Then for pixels in each cell only process those edges.  This is what GLyphy
> does and some of the other solutions as well.
>
> On Tue, Jun 16, 2020 at 8:51 AM Behdad Esfahbod  wrote:
>
>> Hi Anuj,
>>
>> First, let me congratulate you.  This is a very thorough and impressive
>> piece of work for such a short time period.  I read your code over a week
>> ago but couldn't sit down and type this.  I see there has been lots of
>> progress since.  I'll just summarize:
>>
>> - I highly suggest you stick to float internally.  Any fixed-point and
>> you will inevitably hit rasterization issues no matter how hard you try.
>> This is a tried and tested failure path and I encourage you to stay away
>> from it.  I see you did the fixed already.  Have you measured performance?
>> I'm fairly sure the float can be made both more robust and faster.
>> Specially, when and if going for SIMD, you get inverse-sqrt for float but
>> not int and that seems to be the slowest part of your work, which is
>> normalizing vectors.  And I agree, you should do everything in
>> squared-distance, then do a full pass over the results and do the (SIMD if
>> available) sqrt()ing.  I believe you still need normalizing vectors though.
>>
>> - Your Newton-Raphson is solid and your performance numbers look
>> amazing.  I think you should stick with this approach instead of
>> subdividing.  As was suggested by others, do experiment with Raphson on
>> your quadratic as well. A couple things there:
>>
>>   * Currently you abandon as soon as factor falls outside of [0,1].
>> That's wrong.  Factor might go out but come back in in the next iteration.
>>
>>   * I've convinced myself, but probably can't be proved, that MAX_DIVISIONS=2
>> is enough for always finding the closest point. That would speed up
>> significantly.
>>
>> - Your quadratic code always adds t=0 and t=1 as roots. You don't need
>> to. Only clamp the real roots to [0,1] range and remove duplicates.
>>
>> - Your handling of two edges meeting at a corner is solid. That's exactly
>> what we do in GLyphy. However, I'm also now convinced that there is no way
>> to produce SDF from contours that might overlap. Imagine a "+" sign that is
>> two straight contours. You cannot find the distance around the
>> intersection. That's really bad news :(. Removing overlaps is extremely
>> tricky and so far we've stayed away from adding to FreeType. SkiaPathOps
>> seems to be the most solid Open Source implementation. I don't have any
>> suggestion as to how to proceed. I can only say do your work without
>> overlaps and document that as a caveat. I'm sorry I told you you need to do
>> winding tracking. That would help for other reasons, ie. when you have two
>> clockwise circles inside each other and a counter-clockwise one inside
>> those. The middle should be black. To get that black you need to count
>> winding of a ray from point to infinity. That's not what you are doing.
>> Again, okay to initially document that shortcoming.
>>
>> - I still think an option to get A8 output is desired, since that's
>> enough for a respectable rendering in most situations and is 50% more
>> efficient than a 16-bit. Also, most GPU hardware doesn't support 16-bit
>> textures.
>>
>> - There was one place when I checked last week, that you were computing
>> distance then squaring it instead of just getting the squared_distance for
>> which you already had a function.
>>
>> - Your "spread" stuff. Spread is good, and user sets that depends on 1.
>> the width of filter they gonna use for rasterizing, 2. minimum size they
>> want to rasterize at. What that means is:
>>
>> * x_pad / y_pad should be set equal to spread,
>>
>> * The final normalizing you are doing based on max-distance is
>> nonsensical. Makes the SDF unusable for rasterization.
>>
>> Re different filters, I found that they don't really matter. You can see
>> my results in my slides / video:
>>
>> http://behdad.org/glyphy_slides.pdf
>> https://vimeo.com/83732058
>>
>> That's all I remember.  I'll look into your latest code

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

On Mon, Jun 15, 2020 at 9:47 AM Alexei Podtelezhnikov 
wrote:

> On Mon, Jun 15, 2020 at 11:03 AM Anuj Verma  wrote:
> >>
> > > For linear segments, it will save more than 90% according to your
> > > table. Then you will see that splitting Bezier curves is not such a
> > > bad option. In general, Bezier curves are used in graphics because it
> > > is easy to split and flatten them. I would be very surprised if
> > > distance fields were different in this regard?
> >
> > Well, I'm not much familiar with the rendering part of bezier curve.
>
> This primer is fun to read with many interactive demos:
> https://pomax.github.io/bezierinfo/
> The main thing to recognize is that splitting a Bezier at t=0.5 and
> calculating the new set of control points for the halfs is lightning
> fast. If you continue doing so, the segments very quickly converge to
> almost straight (flat) segments.
>

Alexei,

I find your suggestion deeply offensive.  Have you looked at his code?  You
should.  You will learn a few things about writing good code.  This is the
kind of toxic behavior that has been deeply bothering me on this list but I
couldn't fully understand and verbalize.  I'm getting closer to that now.
I will start a new thread when I can write that down.  In the meantime I
think you should apologize to Anuj.


https://www.businessinsider.com/cond-nast-assistant-quit-ceo-gave-her-elements-of-style-2020-6





> > In distance fields I'm just concerned about finding the shortest
> distance as accurate and as fast as possible.
>
> Each split decreases deviation 4 times for a conic segment so that you
> can reach a given accuracy of your distance field and use only
> straight segments. The accuracy is defined by the grid resolution: it
> won't be visible to a human eye if the approximation deviates from a
> true curve by more than ~0.1 of the grid size.
>
>

-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

Oh, I forgot:

After you do all this, you will realize that the speed is still a concern.
Don't do bounding-box check.  Classic way to do after is to split into a
coarse grid and for each cell find all edges that may be relevant.  Then
for pixels in each cell only process those edges.  This is what GLyphy does
and some of the other solutions as well.

On Tue, Jun 16, 2020 at 8:51 AM Behdad Esfahbod  wrote:

> Hi Anuj,
>
> First, let me congratulate you.  This is a very thorough and impressive
> piece of work for such a short time period.  I read your code over a week
> ago but couldn't sit down and type this.  I see there has been lots of
> progress since.  I'll just summarize:
>
> - I highly suggest you stick to float internally.  Any fixed-point and you
> will inevitably hit rasterization issues no matter how hard you try.  This
> is a tried and tested failure path and I encourage you to stay away from
> it.  I see you did the fixed already.  Have you measured performance?  I'm
> fairly sure the float can be made both more robust and faster.  Specially,
> when and if going for SIMD, you get inverse-sqrt for float but not int and
> that seems to be the slowest part of your work, which is normalizing
> vectors.  And I agree, you should do everything in squared-distance, then
> do a full pass over the results and do the (SIMD if available) sqrt()ing.
> I believe you still need normalizing vectors though.
>
> - Your Newton-Raphson is solid and your performance numbers look amazing.
> I think you should stick with this approach instead of subdividing.  As was
> suggested by others, do experiment with Raphson on your quadratic as well.
> A couple things there:
>
>   * Currently you abandon as soon as factor falls outside of [0,1].
> That's wrong.  Factor might go out but come back in in the next iteration.
>
>   * I've convinced myself, but probably can't be proved, that MAX_DIVISIONS=2
> is enough for always finding the closest point. That would speed up
> significantly.
>
> - Your quadratic code always adds t=0 and t=1 as roots. You don't need to.
> Only clamp the real roots to [0,1] range and remove duplicates.
>
> - Your handling of two edges meeting at a corner is solid. That's exactly
> what we do in GLyphy. However, I'm also now convinced that there is no way
> to produce SDF from contours that might overlap. Imagine a "+" sign that is
> two straight contours. You cannot find the distance around the
> intersection. That's really bad news :(. Removing overlaps is extremely
> tricky and so far we've stayed away from adding to FreeType. SkiaPathOps
> seems to be the most solid Open Source implementation. I don't have any
> suggestion as to how to proceed. I can only say do your work without
> overlaps and document that as a caveat. I'm sorry I told you you need to do
> winding tracking. That would help for other reasons, ie. when you have two
> clockwise circles inside each other and a counter-clockwise one inside
> those. The middle should be black. To get that black you need to count
> winding of a ray from point to infinity. That's not what you are doing.
> Again, okay to initially document that shortcoming.
>
> - I still think an option to get A8 output is desired, since that's enough
> for a respectable rendering in most situations and is 50% more efficient
> than a 16-bit. Also, most GPU hardware doesn't support 16-bit textures.
>
> - There was one place when I checked last week, that you were computing
> distance then squaring it instead of just getting the squared_distance for
> which you already had a function.
>
> - Your "spread" stuff. Spread is good, and user sets that depends on 1.
> the width of filter they gonna use for rasterizing, 2. minimum size they
> want to rasterize at. What that means is:
>
> * x_pad / y_pad should be set equal to spread,
>
> * The final normalizing you are doing based on max-distance is
> nonsensical. Makes the SDF unusable for rasterization.
>
> Re different filters, I found that they don't really matter. You can see
> my results in my slides / video:
>
> http://behdad.org/glyphy_slides.pdf
> https://vimeo.com/83732058
>
> That's all I remember.  I'll look into your latest code at some point.
>
> Regards,
> behdad
>
> On Sat, Jun 6, 2020 at 9:51 PM Anuj Verma  wrote:
>
>> Hello All,
>>
>>
>> *> Have you figured out FT_Fixed arithmetic? You still use floats in your
>> > code. I think you should convert to FT_Fixed first. *
>>
>> So, I have been trying to convert my code to FT_Fixed for a few days now
>> without any success.
>> I did manage to use fixed point for shapes with only line segments, but
>> because of small range
>> of 16.1

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

Hi Anuj,

First, let me congratulate you.  This is a very thorough and impressive
piece of work for such a short time period.  I read your code over a week
ago but couldn't sit down and type this.  I see there has been lots of
progress since.  I'll just summarize:

- I highly suggest you stick to float internally.  Any fixed-point and you
will inevitably hit rasterization issues no matter how hard you try.  This
is a tried and tested failure path and I encourage you to stay away from
it.  I see you did the fixed already.  Have you measured performance?  I'm
fairly sure the float can be made both more robust and faster.  Specially,
when and if going for SIMD, you get inverse-sqrt for float but not int and
that seems to be the slowest part of your work, which is normalizing
vectors.  And I agree, you should do everything in squared-distance, then
do a full pass over the results and do the (SIMD if available) sqrt()ing.
I believe you still need normalizing vectors though.

- Your Newton-Raphson is solid and your performance numbers look amazing.
I think you should stick with this approach instead of subdividing.  As was
suggested by others, do experiment with Raphson on your quadratic as well.
A couple things there:

  * Currently you abandon as soon as factor falls outside of [0,1].  That's
wrong.  Factor might go out but come back in in the next iteration.

  * I've convinced myself, but probably can't be proved, that MAX_DIVISIONS=2
is enough for always finding the closest point. That would speed up
significantly.

- Your quadratic code always adds t=0 and t=1 as roots. You don't need to.
Only clamp the real roots to [0,1] range and remove duplicates.

- Your handling of two edges meeting at a corner is solid. That's exactly
what we do in GLyphy. However, I'm also now convinced that there is no way
to produce SDF from contours that might overlap. Imagine a "+" sign that is
two straight contours. You cannot find the distance around the
intersection. That's really bad news :(. Removing overlaps is extremely
tricky and so far we've stayed away from adding to FreeType. SkiaPathOps
seems to be the most solid Open Source implementation. I don't have any
suggestion as to how to proceed. I can only say do your work without
overlaps and document that as a caveat. I'm sorry I told you you need to do
winding tracking. That would help for other reasons, ie. when you have two
clockwise circles inside each other and a counter-clockwise one inside
those. The middle should be black. To get that black you need to count
winding of a ray from point to infinity. That's not what you are doing.
Again, okay to initially document that shortcoming.

- I still think an option to get A8 output is desired, since that's enough
for a respectable rendering in most situations and is 50% more efficient
than a 16-bit. Also, most GPU hardware doesn't support 16-bit textures.

- There was one place when I checked last week, that you were computing
distance then squaring it instead of just getting the squared_distance for
which you already had a function.

- Your "spread" stuff. Spread is good, and user sets that depends on 1. the
width of filter they gonna use for rasterizing, 2. minimum size they want
to rasterize at. What that means is:

* x_pad / y_pad should be set equal to spread,

* The final normalizing you are doing based on max-distance is nonsensical.
Makes the SDF unusable for rasterization.

Re different filters, I found that they don't really matter. You can see my
results in my slides / video:

http://behdad.org/glyphy_slides.pdf
https://vimeo.com/83732058

That's all I remember.  I'll look into your latest code at some point.

Regards,
behdad

On Sat, Jun 6, 2020 at 9:51 PM Anuj Verma  wrote:

> Hello All,
>
>
> *> Have you figured out FT_Fixed arithmetic? You still use floats in your
> > code. I think you should convert to FT_Fixed first. *
>
> So, I have been trying to convert my code to FT_Fixed for a few days now
> without any success.
> I did manage to use fixed point for shapes with only line segments, but
> because of small range
> of 16.16 fixed point I have to use 26.6 for intermediate calculations and
> because of that it
> doesn't look good, (https://imgur.com/kUSIj3y) Here is a comparison
> between float on
> the right and 26.6 fixed point representation on the left.
> As for bezier curves, there is almost always an overflow because while
> solving polynomials some
> large numbers are involved. I even tried using Newton's approximation, but
> it's too slow and still
> not as accurate as floating points. I did not try using 64 bit integers
> because they are not portable
> I guess and because of that I have to create separate implementations for
> 32 and 64 bit architecture.
> So, after comparing both, I prefer floats over fixed points because they
> satisfy both range and precision.
> I can try using 64 bit integers but I am not sure whether I will be able
> to finish the project on time or
> not because of 

Re: Logging Library-GSOC

[Behdad Esfahbod]

I find it a *very* bad idea to have code in FreeType that would write to a
file.  Specially bad if that can be controlled by an env-var.

I still think what's desired can be done best by just revamping and writing
custom code in FreeType itself.

This is my last word on this particular topic, but I'll reply to
genuine technical curiosity.

behdad

On Fri, Jun 12, 2020 at 8:47 AM Priyesh kumar 
wrote:

> Hi Werner,
> I have updated the progress report for this week @ here
> 
>
> Thanks,
> Priyesh
>
> On Sat, Jun 6, 2020 at 8:34 PM Werner LEMBERG  wrote:
>
>>
>> > The gnulib repository provides a module 'unistd' for creating a
>> > 'unistd.h' header file; this works on Windows too.
>> >
>> >   https://www.gnu.org/software/gnulib/
>>
>> By the way, the gnulib repository also provides an interface to
>> threads – including Windows.  If you install the corresponding modules
>> you automatically get a configure option
>>
>>   --enable-threads={posix,windows,isoc}
>>
>> (with MSVC and mingw support for 'windows').  The very recent commit
>> 10cf67b5e333 in the gnulib repository describes the available modules
>> and options for multithreading.
>>
>> Note that my knowledge of thread programming is zero, so please handle
>> my observations with some care.
>>
>> Of course, it is problematic for FreeType license-wise to rely on
>> gnulib since the latter uses the LGPLv2+ license.  On the other hand,
>> linking with a logging library would be mainly used for debugging
>> purposes and not for end products, so a dependency on LGPLv2+ might be
>> OK if the corresponding code is properly guarded with preprecessor
>> conditionals (which is a good idea anyway).
>>
>>
>> Werner
>>
>

-- 
behdad
http://behdad.org/

Re: Logging library

[Behdad Esfahbod]

On Mon, Jun 8, 2020 at 9:53 AM Werner LEMBERG  wrote:

>
> > I want to raise same concerns that David did in a thread a few
> > months ago.
> >
> > I don't think a logging library is neither needed nor appropriate
> > for FreeType.  Werner, can you please summarize why you think this
> > is a good idea?
>
> See
>
>
> https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00148.html
>
> for example.
>
> It's not clear to me why there is so much concern.  The logging
> library stuff will stay optional as a debugging aid and not be part of
> the default production version of FreeType.  How could better logging
> capabilities ever be a bad thing?
>

The logic just doesn't fly.

Logging libraries are used for collecting and filtering and storing logs
*in production systems*.  What you seem to want is better debugging
facilities.  That's it.

You seem to be on the camp of "how can more stuff be a bad idea."  More
stuff *is* bad if those stuff don't serve a real purpose.  Maintenance cost
increase is real.  Bloat is real.  Complexity is real.  FreeType needs
*less* stuff, not *more*.  Same about adding metafont stuff in.  Same about
how otvalid and gxvalid went in.  It's pile of unused untested unneeded
crap.

FreeType needs to change focus.  And I trust David to know what he's
doing.  And you are not listening to him either.

-- 
behdad
http://behdad.org/

Logging library

[Behdad Esfahbod]

I want to raise same concerns that David did in a thread a few months ago.

I don't think a logging library is neither needed nor appropriate for
FreeType.  Werner, can you please summarize why you think this is a good
idea?

-- 
behdad
http://behdad.org/

Re: GSOC - Distance Fields

[Behdad Esfahbod]

For more context: I'm not going to stay silent to your abuse anymore.  You
have no idea what distance-fields are used for, never used one, never
generated one, and you are blocking real constructive discussion from
people who actually know that shit.

On Thu, Jun 4, 2020 at 11:31 AM Behdad Esfahbod  wrote:

> That's BS Alexei.  Eff off.
>
> On Thu, Jun 4, 2020 at 10:28 AM Alexei Podtelezhnikov 
> wrote:
>
>> Jim, Behdad,
>>
>> Please hold your horses. This is Anuj's GSoC project for this summer.
>> It is not nice to take it over until September. For now, please let
>> him explore the field. Feel free to discuss your own implementation in
>> a separate thread or at least povide some explanation instead of
>> abrupt "8.8 makes more sense" or "when I was at Google". This is
>> highly inappropriate as you had your chance to contribute Distance
>> Fields before May and will have it after September.
>>
>> Best regards,
>> Alexei
>>
>>
>>
>>
>> On Thu, Jun 4, 2020 at 12:39 PM Behdad Esfahbod 
>> wrote:
>> >
>> > Thanks Jim.
>> >
>> > A 2.14 representation when 1 unit = 1em is sufficient.  If we are
>> talking pixels then 10.6 or better 8.8 makes more sense.  And I agree that
>> the pixel values are more useful to clients than em values.
>> >
>> > On Thu, Jun 4, 2020 at 8:35 AM Jim Van Verth 
>> wrote:
>> >>
>> >> Behdad,
>> >>
>> >> Thanks for the pointer to cu2qu, I'll take a look at it. I assume
>> you're suggesting we use that in place of GrPathUtils::convertCubicToQuads.
>> I believe in our case we chop at inflections to avoid artifacts from our
>> resolution independent curve rendering.
>> >>
>> >> As far as scale for our SDFs, 1 unit in distance is one pixel. And
>> Anuj, I'm not sure 2.14 is enough precision in the integer part. It's been
>> a while, but I believe I got better results with at least 3 bits of integer.
>> >>
>> >> On Wed, Jun 3, 2020 at 6:33 PM Behdad Esfahbod 
>> wrote:
>> >>>
>> >>> Jim,
>> >>>
>> >>> I see that in your implementation you are converting cubics to
>> quadratic spline.  That makes a lot of sense and I support that.  For the
>> conversion though, I see a messy piece of code, which is typical of that
>> kind of thing.  I like to introduce you to cu2qu algorithm which we
>> designed and implemented back when I was at Google.  It has a much simpler
>> algorithm, which is very robust by design and has been used in production
>> of thousands of fonts in recent years with no bug report whatsoever.  The
>> core algorithm is very simple:
>> >>>
>> >>>
>> https://github.com/googlefonts/cu2qu/blob/master/Lib/cu2qu/cu2qu.py#L218
>> >>>
>> >>> Here's a highlevel description of the algorithm:
>> >>>
>> >>>   https://github.com/googlefonts/cu2qu/issues/10
>> >>>
>> >>> This was specifically designed to have very good behavior for
>> encoding the results in a 'glyf' table.  But is useful for more general
>> uses as well.
>> >>>
>> >>> It would work much better if we break the input curve on cusps if
>> any.  But even that has not been an issue:
>> >>>
>> >>>   https://github.com/googlefonts/cu2qu/issues/6
>> >>>
>> >>> Cheers,
>> >>> behdad
>> >>>
>> >>>
>> >>> On Wed, Jun 3, 2020 at 3:16 PM Behdad Esfahbod 
>> wrote:
>> >>>>
>> >>>> Hi Jim, others,
>> >>>>
>> >>>> Thanks for your input.  I've been meaning to get into the discussion
>> as well but didn't get to.
>> >>>>
>> >>>> I support your suggestions: generate from vector instead of bitmap,
>> as well as 8-bit 3.5 fixed point or similar at least as an option.  In your
>> 3.5 fixed-point, does one unit reflect 1em, or 1 pixel at the SDF size?
>> >>>>
>> >>>> I think we do want a 8bit representation at least, and possible a
>> higher one.
>> >>>>
>> >>>> On Wed, Jun 3, 2020 at 10:26 AM Jim Van Verth 
>> wrote:
>> >>>>>
>> >>>>> Forgive me for coming into this late -- a colleague pointed me to
>> this thread a couple of days ago and I'm just catching up. I work on Skia,
>> and we've been generating SDFs from glyphs for quite some time now, so 

Re: GSOC - Distance Fields

[Behdad Esfahbod]

That's BS Alexei.  Eff off.

On Thu, Jun 4, 2020 at 10:28 AM Alexei Podtelezhnikov 
wrote:

> Jim, Behdad,
>
> Please hold your horses. This is Anuj's GSoC project for this summer.
> It is not nice to take it over until September. For now, please let
> him explore the field. Feel free to discuss your own implementation in
> a separate thread or at least povide some explanation instead of
> abrupt "8.8 makes more sense" or "when I was at Google". This is
> highly inappropriate as you had your chance to contribute Distance
> Fields before May and will have it after September.
>
> Best regards,
> Alexei
>
>
>
>
> On Thu, Jun 4, 2020 at 12:39 PM Behdad Esfahbod  wrote:
> >
> > Thanks Jim.
> >
> > A 2.14 representation when 1 unit = 1em is sufficient.  If we are
> talking pixels then 10.6 or better 8.8 makes more sense.  And I agree that
> the pixel values are more useful to clients than em values.
> >
> > On Thu, Jun 4, 2020 at 8:35 AM Jim Van Verth 
> wrote:
> >>
> >> Behdad,
> >>
> >> Thanks for the pointer to cu2qu, I'll take a look at it. I assume
> you're suggesting we use that in place of GrPathUtils::convertCubicToQuads.
> I believe in our case we chop at inflections to avoid artifacts from our
> resolution independent curve rendering.
> >>
> >> As far as scale for our SDFs, 1 unit in distance is one pixel. And
> Anuj, I'm not sure 2.14 is enough precision in the integer part. It's been
> a while, but I believe I got better results with at least 3 bits of integer.
> >>
> >> On Wed, Jun 3, 2020 at 6:33 PM Behdad Esfahbod 
> wrote:
> >>>
> >>> Jim,
> >>>
> >>> I see that in your implementation you are converting cubics to
> quadratic spline.  That makes a lot of sense and I support that.  For the
> conversion though, I see a messy piece of code, which is typical of that
> kind of thing.  I like to introduce you to cu2qu algorithm which we
> designed and implemented back when I was at Google.  It has a much simpler
> algorithm, which is very robust by design and has been used in production
> of thousands of fonts in recent years with no bug report whatsoever.  The
> core algorithm is very simple:
> >>>
> >>>
> https://github.com/googlefonts/cu2qu/blob/master/Lib/cu2qu/cu2qu.py#L218
> >>>
> >>> Here's a highlevel description of the algorithm:
> >>>
> >>>   https://github.com/googlefonts/cu2qu/issues/10
> >>>
> >>> This was specifically designed to have very good behavior for encoding
> the results in a 'glyf' table.  But is useful for more general uses as well.
> >>>
> >>> It would work much better if we break the input curve on cusps if
> any.  But even that has not been an issue:
> >>>
> >>>   https://github.com/googlefonts/cu2qu/issues/6
> >>>
> >>> Cheers,
> >>> behdad
> >>>
> >>>
> >>> On Wed, Jun 3, 2020 at 3:16 PM Behdad Esfahbod 
> wrote:
> >>>>
> >>>> Hi Jim, others,
> >>>>
> >>>> Thanks for your input.  I've been meaning to get into the discussion
> as well but didn't get to.
> >>>>
> >>>> I support your suggestions: generate from vector instead of bitmap,
> as well as 8-bit 3.5 fixed point or similar at least as an option.  In your
> 3.5 fixed-point, does one unit reflect 1em, or 1 pixel at the SDF size?
> >>>>
> >>>> I think we do want a 8bit representation at least, and possible a
> higher one.
> >>>>
> >>>> On Wed, Jun 3, 2020 at 10:26 AM Jim Van Verth 
> wrote:
> >>>>>
> >>>>> Forgive me for coming into this late -- a colleague pointed me to
> this thread a couple of days ago and I'm just catching up. I work on Skia,
> and we've been generating SDFs from glyphs for quite some time now, so the
> possibility of just getting them from Freetype is pretty exciting.
> >>>>>
> >>>>> I hope you don't mind some comments on what we have now. We
> currently use the Gustavson algorithm to generate them from bitmaps but it
> produces slightly fuzzy results. I have wanted to move to use this
> algorithm to generate them directly from the outline which might be useful
> to you:
> >>>>>
> https://skia.googlesource.com/skia/+/refs/heads/master/src/gpu/GrDistanceFieldGenFromVector.cpp
> >>>>> We use it to store atlased paths at the moment and it produces much
> better results.
> >>>>>
> >>>>> As far as format, we use an 8-bit 3.5 fixed point format, because it
> allows us to combine the SDF and bitmap glyphs into the same atlas to
> conserve space. There is a sacrifice in quality, but we only use the SDFs
> for larger glyphs so it's acceptable.
> >>>>>
> >>>>> If you would like more details on our implementation please let me
> know. I'm looking forward to seeing how this turns out.
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> behdad
> >>>> http://behdad.org/
> >>>
> >>>
> >>>
> >>> --
> >>> behdad
> >>> http://behdad.org/
> >>
> >>
> >>
> >> --
> >>
> >> Jim Van Verth | Software Engineer | jvanve...@google.com | 919-210-7664
> >>
> >
> >
> > --
> > behdad
> > http://behdad.org/
>
>
>
> --
> Alexei A. Podtelezhnikov, PhD
>


-- 
behdad
http://behdad.org/

Re: GSOC - Distance Fields

[Behdad Esfahbod]

Thanks Jim.

A 2.14 representation when 1 unit = 1em is sufficient.  If we are talking
pixels then 10.6 or better 8.8 makes more sense.  And I agree that the
pixel values are more useful to clients than em values.

On Thu, Jun 4, 2020 at 8:35 AM Jim Van Verth  wrote:

> Behdad,
>
> Thanks for the pointer to cu2qu, I'll take a look at it. I assume you're
> suggesting we use that in place of GrPathUtils::convertCubicToQuads. I
> believe in our case we chop at inflections to avoid artifacts from our
> resolution independent curve rendering.
>
> As far as scale for our SDFs, 1 unit in distance is one pixel. And Anuj,
> I'm not sure 2.14 is enough precision in the integer part. It's been a
> while, but I believe I got better results with at least 3 bits of integer.
>
> On Wed, Jun 3, 2020 at 6:33 PM Behdad Esfahbod  wrote:
>
>> Jim,
>>
>> I see that in your implementation you are converting cubics to quadratic
>> spline.  That makes a lot of sense and I support that.  For the conversion
>> though, I see a messy piece of code, which is typical of that kind
>> of thing.  I like to introduce you to cu2qu algorithm which we designed and
>> implemented back when I was at Google.  It has a much simpler algorithm,
>> which is very robust by design and has been used in production of thousands
>> of fonts in recent years with no bug report whatsoever.  The core algorithm
>> is very simple:
>>
>>
>> https://github.com/googlefonts/cu2qu/blob/master/Lib/cu2qu/cu2qu.py#L218
>>
>> Here's a highlevel description of the algorithm:
>>
>>   https://github.com/googlefonts/cu2qu/issues/10
>>
>> This was specifically designed to have very good behavior for encoding
>> the results in a 'glyf' table.  But is useful for more general uses as well.
>>
>> It would work much better if we break the input curve on cusps if any.
>> But even that has not been an issue:
>>
>>   https://github.com/googlefonts/cu2qu/issues/6
>>
>> Cheers,
>> behdad
>>
>>
>> On Wed, Jun 3, 2020 at 3:16 PM Behdad Esfahbod  wrote:
>>
>>> Hi Jim, others,
>>>
>>> Thanks for your input.  I've been meaning to get into the discussion as
>>> well but didn't get to.
>>>
>>> I support your suggestions: generate from vector instead of bitmap, as
>>> well as 8-bit 3.5 fixed point or similar at least as an option.  In your
>>> 3.5 fixed-point, does one unit reflect 1em, or 1 pixel at the SDF size?
>>>
>>> I think we do want a 8bit representation at least, and possible a higher
>>> one.
>>>
>>> On Wed, Jun 3, 2020 at 10:26 AM Jim Van Verth 
>>> wrote:
>>>
>>>> Forgive me for coming into this late -- a colleague pointed me to this
>>>> thread a couple of days ago and I'm just catching up. I work on Skia, and
>>>> we've been generating SDFs from glyphs for quite some time now, so the
>>>> possibility of just getting them from Freetype is pretty exciting.
>>>>
>>>> I hope you don't mind some comments on what we have now. We currently
>>>> use the Gustavson algorithm to generate them from bitmaps but it produces
>>>> slightly fuzzy results. I have wanted to move to use this algorithm to
>>>> generate them directly from the outline which might be useful to you:
>>>>
>>>> https://skia.googlesource.com/skia/+/refs/heads/master/src/gpu/GrDistanceFieldGenFromVector.cpp
>>>> We use it to store atlased paths at the moment and it produces much
>>>> better results.
>>>>
>>>> As far as format, we use an 8-bit 3.5 fixed point format, because it
>>>> allows us to combine the SDF and bitmap glyphs into the same atlas to
>>>> conserve space. There is a sacrifice in quality, but we only use the SDFs
>>>> for larger glyphs so it's acceptable.
>>>>
>>>> If you would like more details on our implementation please let me
>>>> know. I'm looking forward to seeing how this turns out.
>>>>
>>>>
>>>
>>> --
>>> behdad
>>> http://behdad.org/
>>>
>>
>>
>> --
>> behdad
>> http://behdad.org/
>>
>
>
> --
>
> Jim Van Verth | Software Engineer | jvanve...@google.com | 919-210-7664
>
>

-- 
behdad
http://behdad.org/

Re: GSOC - Distance Fields

[Behdad Esfahbod]

Hi Jim, others,

Thanks for your input.  I've been meaning to get into the discussion as
well but didn't get to.

I support your suggestions: generate from vector instead of bitmap, as well
as 8-bit 3.5 fixed point or similar at least as an option.  In your 3.5
fixed-point, does one unit reflect 1em, or 1 pixel at the SDF size?

I think we do want a 8bit representation at least, and possible a higher
one.

On Wed, Jun 3, 2020 at 10:26 AM Jim Van Verth  wrote:

> Forgive me for coming into this late -- a colleague pointed me to this
> thread a couple of days ago and I'm just catching up. I work on Skia, and
> we've been generating SDFs from glyphs for quite some time now, so the
> possibility of just getting them from Freetype is pretty exciting.
>
> I hope you don't mind some comments on what we have now. We currently use
> the Gustavson algorithm to generate them from bitmaps but it produces
> slightly fuzzy results. I have wanted to move to use this algorithm to
> generate them directly from the outline which might be useful to you:
>
> https://skia.googlesource.com/skia/+/refs/heads/master/src/gpu/GrDistanceFieldGenFromVector.cpp
> We use it to store atlased paths at the moment and it produces much better
> results.
>
> As far as format, we use an 8-bit 3.5 fixed point format, because it
> allows us to combine the SDF and bitmap glyphs into the same atlas to
> conserve space. There is a sacrifice in quality, but we only use the SDFs
> for larger glyphs so it's acceptable.
>
> If you would like more details on our implementation please let me know.
> I'm looking forward to seeing how this turns out.
>
>

-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

Anuj,

You cannot use just the orientation of the closest contour.  That's what we
did in GLyphy but is wrong for reasons you found out.  You need to
calculate actual winding number of the sampling point.

On Mon, Jun 1, 2020 at 3:21 AM Anuj Verma  wrote:

> Hello Werner,
>
>
>
> *> As you like.  The idea is that you can go wild within your branch, and
> > that you prepare another, cleaned-up branch for final GSoC submission >
> that contains commits in a logical order.*
>
> In that case I will start integrating the feature in FreeType. I have
> decided to create a new renderer module and add a render mode accordingly.
> And since I have a standalone implementation for generating SDF from
> outlines,
> I will go ahead and do that first and later I will do it for bitmaps.
>
> Thanks,
>
> Anuj
>


-- 
behdad
http://behdad.org/

Re: GSOC - Distance Fields

[Behdad Esfahbod]

Jim,

I see that in your implementation you are converting cubics to quadratic
spline.  That makes a lot of sense and I support that.  For the conversion
though, I see a messy piece of code, which is typical of that kind
of thing.  I like to introduce you to cu2qu algorithm which we designed and
implemented back when I was at Google.  It has a much simpler algorithm,
which is very robust by design and has been used in production of thousands
of fonts in recent years with no bug report whatsoever.  The core algorithm
is very simple:

  https://github.com/googlefonts/cu2qu/blob/master/Lib/cu2qu/cu2qu.py#L218

Here's a highlevel description of the algorithm:

  https://github.com/googlefonts/cu2qu/issues/10

This was specifically designed to have very good behavior for encoding the
results in a 'glyf' table.  But is useful for more general uses as well.

It would work much better if we break the input curve on cusps if any.  But
even that has not been an issue:

  https://github.com/googlefonts/cu2qu/issues/6

Cheers,
behdad


On Wed, Jun 3, 2020 at 3:16 PM Behdad Esfahbod  wrote:

> Hi Jim, others,
>
> Thanks for your input.  I've been meaning to get into the discussion as
> well but didn't get to.
>
> I support your suggestions: generate from vector instead of bitmap, as
> well as 8-bit 3.5 fixed point or similar at least as an option.  In your
> 3.5 fixed-point, does one unit reflect 1em, or 1 pixel at the SDF size?
>
> I think we do want a 8bit representation at least, and possible a higher
> one.
>
> On Wed, Jun 3, 2020 at 10:26 AM Jim Van Verth 
> wrote:
>
>> Forgive me for coming into this late -- a colleague pointed me to this
>> thread a couple of days ago and I'm just catching up. I work on Skia, and
>> we've been generating SDFs from glyphs for quite some time now, so the
>> possibility of just getting them from Freetype is pretty exciting.
>>
>> I hope you don't mind some comments on what we have now. We currently use
>> the Gustavson algorithm to generate them from bitmaps but it produces
>> slightly fuzzy results. I have wanted to move to use this algorithm to
>> generate them directly from the outline which might be useful to you:
>>
>> https://skia.googlesource.com/skia/+/refs/heads/master/src/gpu/GrDistanceFieldGenFromVector.cpp
>> We use it to store atlased paths at the moment and it produces much
>> better results.
>>
>> As far as format, we use an 8-bit 3.5 fixed point format, because it
>> allows us to combine the SDF and bitmap glyphs into the same atlas to
>> conserve space. There is a sacrifice in quality, but we only use the SDFs
>> for larger glyphs so it's acceptable.
>>
>> If you would like more details on our implementation please let me know.
>> I'm looking forward to seeing how this turns out.
>>
>>
>
> --
> behdad
> http://behdad.org/
>


-- 
behdad
http://behdad.org/

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Behdad Esfahbod]

On Mon, Jun 1, 2020 at 3:10 PM Alexei Podtelezhnikov 
wrote:

> On Mon, Jun 1, 2020 at 2:43 PM Werner LEMBERG  wrote:
> > >> However there is an issue with the program, the glyphs which
> > >> contain intersecting contours have an issue.  (example:
> > >> https://imgur.com/MxJfAwY)
> > >
> > > The intersecting contours used to be discouraged and [are] still
> > > quite rare.  [...]
> >
> > This is no longer true: Variation fonts have officially re-introduced
> > intersecting contours.  In other words, it is absolutely necessary to
> > cover this case.
>
> We have issues with that in our rasterizer too, which I do not know
> how to solve short of oversampling. Perhaps, Raph or David have some
> thoughts on how to deal with pixels where contours intersect and
> coverage is calculated wrongly. Whoever let intersections into
> variations fonts should also have some ideas on how to rasterize those
> unless the decision was made hastily.
>

lol.  Intersecting contours have been a reality of TrueType since forever.
The cedilla on a c always overlapped it.  That's why there's a fill rule...


> I still doubt that variation fonts have legs. They were dead in the
> water for 20 years are still too complex to survive, IMHO.
>

You live in your cave.  Varfonts render on billion+ browser installations
and are in use in the wild.

-- 
behdad
http://behdad.org/

Re: Build system considerations

[Behdad Esfahbod]

Let me think about the HarfBuzz co-dependency a bit...

On Mon, May 18, 2020 at 12:26 PM Behdad Esfahbod  wrote:

> Hi David,
>
> Thanks for experimenting with this!
>
> I encourage you to explore removing the Module and Service abstraction
> completely.  We did that in Pango a couple of years ago and never looked
> back...
>
> I'll reply to your original request this week.  Threadsafety and lack of a
> functional separate size object from face is by far the biggest pain point
> of FreeType for heavy users of the library.
>
> b
>
> On Sun, May 17, 2020 at 10:45 AM David Turner  wrote:
>
>> Continuing my own thread, after taking the time to experiment a little.
>>
>> First, I've refactored the build system so we turn the rules.mk into
>> declarative files (instead of Makefile fragments) and get rid of the
>> module.mk files.
>> This allowed me to write a Python script to parse modules.cfg and the
>> various rules.mk to generate a Makefile based on the configuration
>> expressed there.
>> The script is called meta-build.py, and could be easily extended to
>> generate something else if needed, but I haven't gone further than that.
>> However, this let me explore with the exact details on how we configure
>> our build, and the various options to build the library (the generated
>> Makefile allows you to build three variants of the library: a static
>> library and a shared library both compiled with -fPIC, and a static library
>> compiled without it).
>>
>> Second, I wrote support files for the Meson build for the library. It is
>> similar to the CMakeLists.txt version, except for the installation /
>> packaging part. It was a good way to get used to the tool and to compare
>> its system/header/library probing features.
>> In the end, and this is personal opinion, I find Meson cleaner than
>> CMake, sometimes much cleaner, though it has its own little warts that were
>> a bit surprising, as a new comer. Both systems are so much better than
>> auto-tools however.
>>
>> I believe that the ability for any developer to just download a release
>> archive and run "./configure && make" to get a *default build* of the
>> library (and "make install" to install) is really important. I insist on
>> the "default" here, because we have a sophisticated customization system,
>> which was designed in a different time.
>> In other words, before considering switching the build to something else,
>> I propose the following:
>>
>> - Whatever we do, ensuring that "./configure && make && make install"
>> continues to work on Posix systems without extra dependencies. This would
>> only be guaranteed to work on a default build of the library (i.e. without
>> module customization). Configure options would still be provided as usual
>> to handle external dependencies like zlib, libz2, etc.
>>
>> - I would like to drop the dynamic module instantiation / lookup code
>> from the library, to simplify certain code paths. The ability to inject at
>> runtime a new FT_Module was designed at a time where it was expected that
>> people would write custom modules for proprietary/custom font formats, and
>> tools like git which make it easy to rebase changes on top of an upstream
>> project were not available or still very unfamiliar. These days, anyone can
>> create its own fork of an open-source library to add custom features for
>> its own little embedded project. This means no more modules.cfg, and
>> ftmodule.h auto-generation, which are fortunately implementation details.
>> For ABI stability, we will have to keep functions like FT_Add_Module(), but
>> just change them to return an FT_Err_Unimplemented_Feature error code.
>>
>> - I would like to ensure src/base/ftsystem.c does the right thing for all
>> systems. These days, we can avoid probing for  and  and
>> assume a Posix system provides a valid mmap() / munmap() implementation.
>> This will remove one more reason to use auto-tools.
>> - Similarly, there are several versions of ftdebug.c which are
>> essentially similar except for two things: How messages are sent to "the
>> log" (stderr by default), and how to parse the FT2_DEBUG environment
>> variable (when such thing exists). These two things can be encapsulated in
>> a separate file.
>> - Also, we don't need to support 8.3 Filepathnames (DOS and Windows 9x
>> development are long dead), so we can finally use longer filenames (e.g.
>> ftdebug_posix.cc, ftdebug_windows.cc, etc..) to better differentiate the
>> files under src/base/ inst

Re: Build system considerations

[Behdad Esfahbod]

Hi David,

Thanks for experimenting with this!

I encourage you to explore removing the Module and Service abstraction
completely.  We did that in Pango a couple of years ago and never looked
back...

I'll reply to your original request this week.  Threadsafety and lack of a
functional separate size object from face is by far the biggest pain point
of FreeType for heavy users of the library.

b

On Sun, May 17, 2020 at 10:45 AM David Turner  wrote:

> Continuing my own thread, after taking the time to experiment a little.
>
> First, I've refactored the build system so we turn the rules.mk into
> declarative files (instead of Makefile fragments) and get rid of the
> module.mk files.
> This allowed me to write a Python script to parse modules.cfg and the
> various rules.mk to generate a Makefile based on the configuration
> expressed there.
> The script is called meta-build.py, and could be easily extended to
> generate something else if needed, but I haven't gone further than that.
> However, this let me explore with the exact details on how we configure
> our build, and the various options to build the library (the generated
> Makefile allows you to build three variants of the library: a static
> library and a shared library both compiled with -fPIC, and a static library
> compiled without it).
>
> Second, I wrote support files for the Meson build for the library. It is
> similar to the CMakeLists.txt version, except for the installation /
> packaging part. It was a good way to get used to the tool and to compare
> its system/header/library probing features.
> In the end, and this is personal opinion, I find Meson cleaner than CMake,
> sometimes much cleaner, though it has its own little warts that were a bit
> surprising, as a new comer. Both systems are so much better than auto-tools
> however.
>
> I believe that the ability for any developer to just download a release
> archive and run "./configure && make" to get a *default build* of the
> library (and "make install" to install) is really important. I insist on
> the "default" here, because we have a sophisticated customization system,
> which was designed in a different time.
> In other words, before considering switching the build to something else,
> I propose the following:
>
> - Whatever we do, ensuring that "./configure && make && make install"
> continues to work on Posix systems without extra dependencies. This would
> only be guaranteed to work on a default build of the library (i.e. without
> module customization). Configure options would still be provided as usual
> to handle external dependencies like zlib, libz2, etc.
>
> - I would like to drop the dynamic module instantiation / lookup code from
> the library, to simplify certain code paths. The ability to inject at
> runtime a new FT_Module was designed at a time where it was expected that
> people would write custom modules for proprietary/custom font formats, and
> tools like git which make it easy to rebase changes on top of an upstream
> project were not available or still very unfamiliar. These days, anyone can
> create its own fork of an open-source library to add custom features for
> its own little embedded project. This means no more modules.cfg, and
> ftmodule.h auto-generation, which are fortunately implementation details.
> For ABI stability, we will have to keep functions like FT_Add_Module(), but
> just change them to return an FT_Err_Unimplemented_Feature error code.
>
> - I would like to ensure src/base/ftsystem.c does the right thing for all
> systems. These days, we can avoid probing for  and  and
> assume a Posix system provides a valid mmap() / munmap() implementation.
> This will remove one more reason to use auto-tools.
> - Similarly, there are several versions of ftdebug.c which are essentially
> similar except for two things: How messages are sent to "the log" (stderr
> by default), and how to parse the FT2_DEBUG environment variable (when such
> thing exists). These two things can be encapsulated in a separate file.
> - Also, we don't need to support 8.3 Filepathnames (DOS and Windows 9x
> development are long dead), so we can finally use longer filenames (e.g.
> ftdebug_posix.cc, ftdebug_windows.cc, etc..) to better differentiate the
> files under src/base/ instead of sprinkling them under builds//
> - It also means we can probably drop some of the ugly macros for header
> files we're using (still provide them for the API, but change all users
> otherwise). Yeah!
> - Regarding ftdebug.c and logging, we probably want the customizable
> "message" function to take several parameters, e.g.: void
> FT_Log_Message(int trace_component, int trace_level, const char* fmt,
> va_list args). It's possible to consider trace events (i.e. "start/stop")
> to generate flame graph that are easier to read.
> - There are different versions of ftconfig.h, with a ton of stuff shared
> between them, we should probably move these to common header files whenever
> possible.
> - Similarly 

Re: Build system considerations

[Behdad Esfahbod]

Hi David,

Thanks for bringing this up.  I come from the GNOME camp.  My understanding
is that meson is replacing autotools longterm, sidestepping attempts like
cmake, the same way that git replaced CVS, sidestepping mercurial, bazaar,
etc.

In the latest HarfBuzz release we added a meson build system.  Over the
next few months I expect us to remove our cmake one and eventually the
autotools one (which is the "official" one right now).

Hope that helps,
behdad

On Wed, Apr 29, 2020 at 5:34 PM David Turner  wrote:

> Starting a thread here to discuss potential build system improvements for
> FreeType.
>
> The current FreeType 2 build system has many flaws. To its credit, it was
> designed in a very different time, when things like CMake / Meson / Ninja/
> Maven / GN / Bazel didn't even exist, when Autotools was considered the
> best system to configure your build (ah!), and GNU Make 3.81 was considered
> new and bleeding edge, and didn't necessarily exist for all platforms. I'm
> not even sure pkg-config was available on all Linux distros until quite a
> long time. As I said ... very different times.
>
> Despite that, it was also designed to make FreeType buildable on a maximum
> amount of systems, and I attribute part of its success to that specific
> feature, especially in the embedded world. While we probably no longer care
> about developers using DOS and OS/2 systems to build the library, I would
> really appreciate if any replacement could continue in this direction.
>
> I think it would also be acceptable if the build system used to develop
> FreeType itself, might be different than the one used by other developers
> that simply want to use it in their own projects. For example something
> that can build and run tests easily with sanitizers, fuzzing, remote bots
> and other goodies, or can integrate well with a continuous integration
> system. While at the same time, being able to generate simple Makefiles /
> CMakefiles / BUILD / BUILD.gn / whatever corresponding to a specific
> configuration of the library (which is what 95% of developers using the
> library need).
>
> I have experience with CMake (I find it a vast improvement over auto-tools
> for package / feature detection, but a hot mess for about anything else),
> GN/Ninja (very powerful, but essentially requires too much dependencies to
> get the most out of it) and Bazel (can be hard to get into, very powerful,
> but requirements are a bit crazy at the moment). I'm curious about Meson.
>
> I don't have something specific to propose, but that's my current point of
> view. I may be wrong or misguided, so please share your feedback in this
> thread.
>
> Let the flame^W war^W games begin :-)
>
> - David
>
>

-- 
behdad
http://behdad.org/

Re: Blending non-color glyphs

[Behdad Esfahbod]

Hi Werner,

On Thu, Nov 21, 2019 at 8:51 AM Werner LEMBERG  wrote:

>
> Hello Behdad,
>
> > I like to compose multiple glyphs in a bitmap without using any
> > graphics library.  I found that FT_Bitmap_Blend() does exactly what
> > I want except that if none of the glyphs are color, it still
> > promotes the image to a color bitmap.
> >
> > Would be nice to have another version that would only upgrade to
> > color if necessary.
>
> could you provide a patch?
>

I will, after I figure it out.

Another oddity is that this function does NOT transfer directly if source
is color bitmap.  It will flatten it to grayscale then blend that with
provided foreground color.

I understand this was added to implement the MS COLR/CPAL stuff.  But can
be made a lot more useful with the two changes I'm requesting now.

b

>
> Werner
>


-- 
behdad
http://behdad.org/

Re: Two minor build fixes

[Behdad Esfahbod]

On Thu, Nov 21, 2019 at 3:15 PM Werner LEMBERG  wrote:

>
> > I need these in my custom build setup.  Looks correct to me.
>
> Will apply, thanks.
>
> However: The `aflatin2' stuff is never activated; I'm not sure whether
> it still compiles at all.  What are you doing with it?


Right.  I need to figure out how to build.  Ignore that I tried to compile
that file.


-- 
behdad
http://behdad.org/

Two minor build fixes

[Behdad Esfahbod]

I need these in my custom build setup.  Looks correct to me.

Thanks
-- 
behdad
http://behdad.org/
diff --git a/src/autofit/aflatin2.c b/src/autofit/aflatin2.c
index c601ab8d9..dab86dde6 100644
--- a/src/autofit/aflatin2.c
+++ b/src/autofit/aflatin2.c
@@ -21,6 +21,7 @@
  */
 
 
+#include 
 #include FT_ADVANCES_H
 
 
diff --git a/src/gzip/infutil.h b/src/gzip/infutil.h
index 7174b6dd0..cdf18b4f9 100644
--- a/src/gzip/infutil.h
+++ b/src/gzip/infutil.h
@@ -86,7 +86,7 @@ struct inflate_blocks_state {
 
 /* masks for lower bits (size given to avoid silly warnings with Visual C++) */
 #ifndef NO_INFLATE_MASK
-local uInt inflate_mask[17];
+local const uInt inflate_mask[17];
 #endif
 
 /* copy as much as possible from the sliding window to the output area */

Blending non-color glyphs

[Behdad Esfahbod]

Hi,

I like to compose multiple glyphs in a bitmap without using any graphics
library.  I found that FT_Bitmap_Blend() does exactly what I want except
that if none of the glyphs are color, it still promotes the image to a
color bitmap.

Would be nice to have another version that would only upgrade to color if
necessary.

-- 
behdad
http://behdad.org/

Re: [ft-devel] Glitchy rendering of overlapping outlines in variable fonts

[Behdad Esfahbod]

Yes.

On Wed, Sep 25, 2019 at 1:38 PM Nikolaus Waxweiler 
wrote:

> Hi list,
> I was just looking at SourceSerifVariable-Roman.otf from
> https://github.com/adobe-fonts/source-serif-pro/releases/tag/3.000R and
> found this discrepancy between the variable instance of Black and the
> static one with overlaps removed:
>
> https://i.postimg.cc/VLLmQqV2/Bildschirmfoto-vom-2019-09-25-21-22-01.png
>
> Same thing in the variable TTF. Is this a known limitation in the
> renderer?
>
>
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype2] hooks-via-module-property d94f52b: Use `FT_Property_Set' to set the hooks. One less API function.

[Behdad Esfahbod]

On Tue, Aug 20, 2019 at 11:35 AM Werner LEMBERG  wrote:

>
> > [...], after this commit, I am not abusing it to set pointer to
> > code.  I am abusing it to set a structure of four function pointers.
> >
> > Let me know if your concerns remain the same with this change.
>
> His concerns stay the same.  He doesn't like `multi-purpose' API calls
> that do more than a single thing, and which use casts to various types
> like the mentioned `ioctl' function.  Having a structure certainly
> reduces possible coding errors, but in the end there is still a cast
> from one type to another, something that disables type checking on the
> compiler level.
>
> However, for the sake of consistency with other module controlling
> stuff, I prefer it how you've implemented it.
>

Sure, not quite my problem... but does this mean one can crash
FreeType-using apps by just setting an environment variable?


> The current API of FreeType has many flaws, mainly due to its age.
> Unfortunately, I'm bad at designing something completely new.  In case
> there are volunteers who are *seriously* interested in doing that to
> modernize FreeType (producing a version 3 that doesn't need to be
> compatible to version 2): Please come forward and show up!
>
>
> Werner
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype2] hooks-via-module-property d94f52b: Use `FT_Property_Set' to set the hooks. One less API function.

[Behdad Esfahbod]

On Fri, Jul 19, 2019 at 4:34 PM Moazin Khatri 
wrote:

> Just want to express that this is very, *very*, /very/, VERY, bad.
>>
>
> Thank you for pointing that out. However, ...
>
> The whole property API is a big anti-pattern that FreeType has adopted.
>> Still, using it to set boolean, integer, or string values is justifiable.
>>
>
> Please explain to me why it's an "anti-pattern"? What's wrong with the
> property API? What could be a better alternative? Just for my
> own understanding! :)
>

It should go the other way around.  You should explain what you gain by
using this scheme instead of what's standard practice in the language we
are dealing with (C).

For all I see you are throwing out type safety and things that compiler and
linker can check for, to gain nothing.  "Fewer API" is not a goal.  It
shouldn't be.  Why don't we move ALL API into that one call?!

Also Google around why ioctl is a bad syscall for example.

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics

[Behdad Esfahbod]

I'm not sure what exactly points of discussion are, but in HarfBuzz we do
purposefully ignore position overflows.  We use a macro like this for that:

#define HB_NO_SANITIZE_SIGNED_INTEGER_OVERFLOW
__attribute__((no_sanitize("signed-integer-overflow")))

If you want to copy the macro, please copy its surrounding conditions as
well.

b

On Tue, Aug 13, 2019 at 3:04 PM  wrote:

> >> Whether with -wrapv or with the unsigned macros, we simply disable
> >> some compiler optimizations, perhaps some good optimizations too.
> >
> > Most certainly, yes.  But there are a lot more things that slow down the
> > potential performance of FreeType -- C in itself is a trade-off between
> > maintainability and performance.
> >
> >> Why? Is it because we got scared? There is absolutely no evidence of
> >> real bugs in FreeType. It is reasonable to disable optimizations with
> >> -wrapv, if scared, but macros are too rigid. Some compilers recognize
> >> /* fall through */ comment to suppress particular warnings. I wish we
> >> could just add a comment to silence these warnings after adjudication.
> >
> > It's not about being scared but about making sure we understand _what_
> the
> > code within FT does.  If we proactively mark operations that have a
> certain
> > behaviour we make those operations explicit to whomever reads that thing
> in
> > the future.  `-wrapv' has two downsides IMO:  (1) we lose track of what
> it
> > does and _where_ ... maybe, really covering up bugs (2) we rely on 3rd
> parties
> > to compile FT in a very specific way to avoid certain types of reports.
>
> For reference, find the patch attached (most code in that area is already
> wrapped in `*_LONG' macros).
>
> @Werner: should I apply it?
>
> Armin
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype2] GSoC-2019-moazin 8887048: Performs basic to see if SVG data is valid or not.

[Behdad Esfahbod]

Don't.

Don't check things your code doesn't rely on.  That just bloats code and
makes assumptions that just end up being wrong and make others' life harder
in the future.

On Mon, Jul 29, 2019 at 1:02 PM Moazin Khatri 
wrote:

> I see similar checks in `ttcpal.c' and many other places.
> Invalid data is checked for and rejected, so decided to do
> the same.
>
> On Tue, Jul 30, 2019 at 12:59 AM Behdad Esfahbod 
> wrote:
>
>> Why?
>>
>> On Mon, Jul 29, 2019 at 12:41 PM Moazin Khatti 
>> wrote:
>>
>>> branch: GSoC-2019-moazin
>>> commit 8887048557db93857ffa6169cfe4c3190f9cb1a1
>>> Author: Moazin Khatti 
>>> Commit: Moazin Khatti 
>>>
>>> Performs basic to see if SVG data is valid or not.
>>> ---
>>>  src/sfnt/ttsvg.c | 38 --
>>>  1 file changed, 36 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/sfnt/ttsvg.c b/src/sfnt/ttsvg.c
>>> index f4a85ca..223eb88 100644
>>> --- a/src/sfnt/ttsvg.c
>>> +++ b/src/sfnt/ttsvg.c
>>> @@ -35,6 +35,24 @@
>>>
>>>  #include "ttsvg.h"
>>>
>>> +/* SVG table looks like:
>>> + * --
>>> + * Bytes: Field |
>>> + * --
>>> + * 2  version
>>> + * 4  offsetToSVGDocumentList
>>> + * 4  reserved
>>> + * 2  numEntries (non-zero)
>>> + * 12*numEntries  documentList
>>> + *
>>> + * Since numEntries must be at least one, minimum
>>> + * size of SVG table is 24. Everything apart from
>>> + * the documentList makes 12 bytes.
>>> + */
>>> +
>>> +#define  SVG_HEADER_BASE_SIZE 12
>>> +#define  SVG_HEADER_MIN_SIZE  24
>>> +
>>>/* TODO: (OT-SVG) Decide whether to add documentation here or not */
>>>
>>>typedef struct Svg_
>>> @@ -69,6 +87,9 @@
>>>  if( error )
>>>goto NoSVG;
>>>
>>> +if ( table_size < SVG_HEADER_MIN_SIZE )
>>> +  goto InvalidTable;
>>> +
>>>  if( FT_FRAME_EXTRACT( table_size, table ))
>>>goto NoSVG;
>>>
>>> @@ -77,7 +98,14 @@
>>>goto NoSVG;
>>>
>>>  p = table;
>>> -svg->version =FT_NEXT_USHORT( p );
>>> +svg->version = FT_NEXT_USHORT( p );
>>> +
>>> +/* At the time of writing this, only version 0 exists,
>>> + * and only that is supported by FreeType
>>> + */
>>> +if ( svg->version != 0 )
>>> +  goto InvalidTable;
>>> +
>>>  offsetToSVGDocumentList = FT_NEXT_ULONG( p );
>>>
>>>  if( offsetToSVGDocumentList == 0 )
>>> @@ -88,6 +116,9 @@
>>>  p = svg->svg_doc_list;
>>>  svg->num_entries = FT_NEXT_USHORT( p );
>>>
>>> +if ( ( svg->num_entries*12 + SVG_HEADER_BASE_SIZE ) > table_size )
>>> +  goto InvalidTable;
>>> +
>>>  FT_TRACE3(( "version: %d\n", svg->version ));
>>>  FT_TRACE3(( "num entiries: %d\n", svg->num_entries ));
>>>
>>> @@ -244,7 +275,10 @@
>>>*doc_length = mid_doc.length;
>>>*start_glyph = mid_doc.start_glyph_id;
>>>*end_glyph   = mid_doc.end_glyph_id;
>>> -  error = FT_Err_Ok;
>>> +  if ( *doc_length == 0 )
>>> +error = FT_THROW( Invalid_SVG_Document );
>>> +  else
>>> +error = FT_Err_Ok;
>>>  }
>>>  return error;
>>>}
>>>
>>>
>>
>> --
>> behdad
>> http://behdad.org/
>>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype2] GSoC-2019-moazin 8887048: Performs basic to see if SVG data is valid or not.

[Behdad Esfahbod]

Why?

On Mon, Jul 29, 2019 at 12:41 PM Moazin Khatti 
wrote:

> branch: GSoC-2019-moazin
> commit 8887048557db93857ffa6169cfe4c3190f9cb1a1
> Author: Moazin Khatti 
> Commit: Moazin Khatti 
>
> Performs basic to see if SVG data is valid or not.
> ---
>  src/sfnt/ttsvg.c | 38 --
>  1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/src/sfnt/ttsvg.c b/src/sfnt/ttsvg.c
> index f4a85ca..223eb88 100644
> --- a/src/sfnt/ttsvg.c
> +++ b/src/sfnt/ttsvg.c
> @@ -35,6 +35,24 @@
>
>  #include "ttsvg.h"
>
> +/* SVG table looks like:
> + * --
> + * Bytes: Field |
> + * --
> + * 2  version
> + * 4  offsetToSVGDocumentList
> + * 4  reserved
> + * 2  numEntries (non-zero)
> + * 12*numEntries  documentList
> + *
> + * Since numEntries must be at least one, minimum
> + * size of SVG table is 24. Everything apart from
> + * the documentList makes 12 bytes.
> + */
> +
> +#define  SVG_HEADER_BASE_SIZE 12
> +#define  SVG_HEADER_MIN_SIZE  24
> +
>/* TODO: (OT-SVG) Decide whether to add documentation here or not */
>
>typedef struct Svg_
> @@ -69,6 +87,9 @@
>  if( error )
>goto NoSVG;
>
> +if ( table_size < SVG_HEADER_MIN_SIZE )
> +  goto InvalidTable;
> +
>  if( FT_FRAME_EXTRACT( table_size, table ))
>goto NoSVG;
>
> @@ -77,7 +98,14 @@
>goto NoSVG;
>
>  p = table;
> -svg->version =FT_NEXT_USHORT( p );
> +svg->version = FT_NEXT_USHORT( p );
> +
> +/* At the time of writing this, only version 0 exists,
> + * and only that is supported by FreeType
> + */
> +if ( svg->version != 0 )
> +  goto InvalidTable;
> +
>  offsetToSVGDocumentList = FT_NEXT_ULONG( p );
>
>  if( offsetToSVGDocumentList == 0 )
> @@ -88,6 +116,9 @@
>  p = svg->svg_doc_list;
>  svg->num_entries = FT_NEXT_USHORT( p );
>
> +if ( ( svg->num_entries*12 + SVG_HEADER_BASE_SIZE ) > table_size )
> +  goto InvalidTable;
> +
>  FT_TRACE3(( "version: %d\n", svg->version ));
>  FT_TRACE3(( "num entiries: %d\n", svg->num_entries ));
>
> @@ -244,7 +275,10 @@
>*doc_length = mid_doc.length;
>*start_glyph = mid_doc.start_glyph_id;
>*end_glyph   = mid_doc.end_glyph_id;
> -  error = FT_Err_Ok;
> +  if ( *doc_length == 0 )
> +error = FT_THROW( Invalid_SVG_Document );
> +  else
> +error = FT_Err_Ok;
>  }
>  return error;
>}
>
>

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG: Feature requirements from SVG rendering library

[Behdad Esfahbod]

Cairo has a "recording surface" which
has _cairo_recording_surface_get_bounds().

On Thu, Jul 25, 2019 at 2:43 PM Alexei Podtelezhnikov 
wrote:

> Hi Moazin,
>
> Can any of SVG libraries return a bounding box without actual
> rendering? Do they have something for FT_RendererClass.get_glyph_cbox?
> This can be hugely useful.
>
> Alexei
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Where is FT_Library reference for FT_MM_Var?

[Behdad Esfahbod]

You're not missing anything...

Face->GlyphSlot->Library...

On Thu, Jul 25, 2019, 4:47 AM Akira TAGOH  wrote:

> Hi,
>
> FT_MM_Var instance can be created without FT_Library instance in its
> scope. but FT_Library is required to free it with FT_Done_MM_Var. How
> can it be freed to avoid the memory leak?
> Apparently there are no reference in even FT_Face nor FT_MM_Var though.
>
> If I'm missing something, please let me know.
>
> TIA,
> --
> Akira TAGOH
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype2] hooks-via-module-property d94f52b: Use `FT_Property_Set' to set the hooks. One less API function.

[Behdad Esfahbod]

Just want to express that this is very, *very*, /very/, VERY, bad.

The whole property API is a big anti-pattern that FreeType has adopted.
Still, using it to set boolean, integer, or string values is justifiable.

Abusing it to set pointer to code, Just Unacceptable.

b

On Wed, Jul 17, 2019 at 11:32 AM Moazin Khatti 
wrote:

> branch: hooks-via-module-property
> commit d94f52b0c698b7358210c13988ccaf6a8d25afc8
> Author: Moazin Khatti 
> Commit: Moazin Khatti 
>
> Use `FT_Property_Set' to set the hooks. One less API function.
> ---
>  include/freetype/svgrender.h |  72 --
>  src/base/ftobjs.c|  43 --
>  src/svg/ftsvg.c  | 101
> ++-
>  3 files changed, 81 insertions(+), 135 deletions(-)
>
> diff --git a/include/freetype/svgrender.h b/include/freetype/svgrender.h
> index 181bfea..670e93f 100644
> --- a/include/freetype/svgrender.h
> +++ b/include/freetype/svgrender.h
> @@ -121,78 +121,6 @@ FT_BEGIN_HEADER
>(*SVG_Lib_Get_Buffer_Size_Func)( FT_GlyphSlot  slot,
> FT_BBox   bbox );
>
> -
> -
> /**
> -   *
> -   * @functype:
> -   *   SVG_Set_Hooks_Func
> -   *
> -   * @description:
> -   *   A function that is used set SVG Hooks.   Part of the SVG Renderer
> -   *   Interface.
> -   *
> -   * @input:
> -   *   module ::
> -   * `FT_Module` instance.
> -   *
> -   *   init_svg ::
> -   * A function pointer of the type `SVG_Lib_Init_Func`.  Read the
> -   * documentation of `SVG_Lib_Init_Func`.
> -   *
> -   *   free_svg ::
> -   * A function pointer of the type `SVG_Lib_Free_Func`.  Read the
> -   * documentation of `SVG_Lib_Free_Func`.
> -   *
> -   *   render_svg ::
> -   * A function pointer of the type `SVG_Lib_Render_Func`.  Read the
> -   * documentation of `SVG_Lib_Render_Func`.
> -   *
> -   *   get_buffer_size ::
> -   * A function pointer of the type `SVG_Lib_Get_Buffer_Size_Func`.
> -   * Read the documentation of `SVG_Lib_Get_Buffer_Size_Func`.
> -   *
> -   * @return:
> -   *   FreeType error code.  0 means success.
> -   */
> -
> -  typedef FT_Error
> -  (*SVG_Set_Hooks_Func)( FT_Module module,
> - SVG_Lib_Init_Func init_svg,
> - SVG_Lib_Free_Func free_svg,
> - SVG_Lib_Render_Func   render_svg,
> - SVG_Lib_Get_Buffer_Size_Func  get_buffer_size );
> -
> -
> /**
> -   *
> -   * @struct:
> -   *   SVG_Renderer_Interface
> -   *
> -   * @description:
> -   *   An interface structure that function needed to inject external SVG
> -   *   rendering library hooks.
> -   *
> -   * @fields:
> -   *   set_hooks ::
> -   * A function that can be called to set the hooks.
> -   *
> -   * @return:
> -   *   FreeType error code.  0 means success.
> -   */
> -
> -  typedef struct SVG_Renderer_Interface_
> -  {
> -SVG_Set_Hooks_Func  set_hooks;
> -  } SVG_Renderer_Interface;
> -
> -
> -  /* TODO: to document */
> -  FT_EXPORT( FT_Error )
> -  FT_Set_Svg_Hooks( FT_Librarylibrary,
> -SVG_Lib_Init_Func init_svg,
> -SVG_Lib_Free_Func free_svg,
> -SVG_Lib_Render_Func   render_svg,
> -SVG_Lib_Get_Buffer_Size_Func  get_buffer_size );
> -
>
>  /**
> *
> * @struct:
> diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
> index 5bf065f..dc71a98 100644
> --- a/src/base/ftobjs.c
> +++ b/src/base/ftobjs.c
> @@ -5603,47 +5603,4 @@
>return 0;
>}
>
> -#ifdef FT_CONFIG_OPTION_SVG
> -  FT_EXPORT_DEF( FT_Error )
> -  FT_Set_Svg_Hooks( FT_Librarylibrary,
> -SVG_Lib_Init_Func init_svg,
> -SVG_Lib_Free_Func free_svg,
> -SVG_Lib_Render_Func   render_svg,
> -SVG_Lib_Get_Buffer_Size_Func  get_buffer_size )
> -  {
> -FT_Module   renderer;
> -SVG_Renderer_Interface  *svg;
> -
> -/* TODO: (OT-SVG) Handle the case if the module is not found */
> -renderer = FT_Get_Module( library, "ot-svg" );
> -
> -/* If ot-svg module is not available return with error */
> -if ( renderer == 0 )
> -  return FT_THROW( Missing_Module );
> -
> -svg = (SVG_Renderer_Interface*)renderer->clazz->module_interface;
> -svg->set_hooks(renderer,
> -   init_svg,
> -   free_svg,
> -   render_svg,
> -   get_buffer_size );
> -return FT_Err_Ok;
> -  }
> -#else
> -  FT_EXPORT_DEF( FT_Error )
> -  FT_Set_Svg_Hooks( FT_Library   

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 6

[Behdad Esfahbod]

On Wed, Jul 17, 2019 at 8:37 AM Moazin Khatri 
wrote:

>   --with-svg=autoeither `yes' or `no', depending on what the
>>  system provides
>>
>
> Werner, can you please elaborate what you mean by
> "what the system provides". I understood the rest of
> the options.
>

What is available. What is installed...

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 6

[Behdad Esfahbod]

On Wed, Jul 17, 2019 at 6:00 AM Alexei Podtelezhnikov 
wrote:

> > > Or, you can just prioritize the separate renderers. Do not waste
> > > your work.
> >
> > While the concept of having different renderers sounds nice in theory,
> > I think it is a hassle to implement, since it moves the burden of
> > properly supporting various SVG rendering libraries to FreeType.
> >
> > I still favour the model of having a *single* default renderer for
> > SVG, providing hooks that can be overridden at run-time for another
> > library.
>
> Werner, Moazin,
>
> This is not user friendly and users will resist it. How many calls a
> user has to make to initialize the library:
> 1) FT_Init_FreeType
> 2) FT_Library_SetLcdFilter (how many people forget this already)
> 3) FT_Property_Set
> 4) FT_Set_SvgHooks (at least use FT_Property_Set instead)
>

Quite on the contrary.  Since FreeType is the kind of library that needs
explicit initialization anyway, adding one more line there is trivial.
Some libraries (like HarfBuzz) don't have explicit initializations.  It
would be more annoying in those libraries if something similar was
required...

librsvg depends on cairo which depends on freetype.  Any SVG renderer
optionally-supporting-text would depend on FreeType.  Don't add these
recursive dependency cycles.  Client should just add one call that's it.
No default required.



> All I care is that the SVG rendering is properly abstracted as a
> renderer module that can be FT_Add/Remove_Module and customized by
> FT_Property_Set. Moazin made the right steps already by removing any
> special code form FT_Render_Glyph_Internal.
>
> Thank you,
> Alexei
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks

[Behdad Esfahbod]

I haven't read the entire thread carefully.  However I want to point out
that how the SVG library allocates and frees memory is its own business and
should NOT be tied to FreeType memory routines.

You still need to negotiate the bitmap allocation though.

On Sat, Jul 6, 2019 at 5:55 AM Moazin Khatri  wrote:

> Hi everyone,
>
> As Behdad adviced, I removed the rendering port's state from the global
> scope and instead decided to store it in `FT_LibraryRec'. The first thing I
> realized was that the state would be of a different type for each SVG
> rendering library, thus, it seemed pointless to add a new structure in
> `FT_LibraryRec'. Instead, I just added a new field `svg_renderer_state'
> which is a `void *'. Now every library could create their own structure and
> reference it inside `FT_LibraryRec'. However, for that to happen, memory
> needs to be allocated and freed by the port, which brought me back to the
> problem I discussed a day ago here
> .
> `ft_mem_*' cannot be accessed from outside FreeType if the client program
> is linking dynamically.
>
> To solve this issue, memory allocation needs to be performed from the
> FreeType side. Thus I added a new hook `get_state_size' which will be
> called to query the size of the `state' structure of a particular port.
> Then FreeType can allocate this memory and later free it too. I did the
> same thing for the image buffer. I created a new hook `get_buffer_size'
> which can be called to query the size needed to place the final rendered
> image. The rendering port uses this memory and it sets the
> `FT_GLYPH_OWN_BITMAP' flag, thus, FreeType can free it later.
>
> This has fixed ALL of the memory leaks I was aware of. I have checked
> using the FreeType memory debugger as well as `valgrind'. The code works on
> all the fonts and test fonts I had and also works with FreeType demo tools.
>
> Please have a look at my latest commit
> 
>  in
> FreeType repo and the last commit 4c86cca
> 
>  of
> my `resvg' port to take a look at these new changes.
>
> Let me know what you guys think about this solution (adding two new hooks
> to query the required memory and allocating it on FreeType side). I'm
> having mixed feelings about this! :D
>
> Best,
>
> Moazin
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks

[Behdad Esfahbod]

Use cairo_image_surface_create_for_data().

On Fri, Jul 5, 2019 at 6:37 AM Moazin Khatri  wrote:

> Hi,
>
> I'm trying to fix all of the memory leaks in the work that I have
> done so far and one very important memory leak is that of the whole
> image buffer data.
>
> For example, in my `resvg' port, after the SVG document has been
> rendered to a cairo surface, I use `cairo_image_surface_get_data'
> to get a pointer to the actual image data and just set the
> `slot->bitmap.buffer' to this pointer. This works, but the problem
> is freeing this memory later on. All of this memory was allocated
> by cairo and the right way to free is by `cairo_surface_destroy'.
> But we don't wanna free it immediately, only after the user has
> done their thing with the data.
>
> We could solve this by creating another hook that will be triggered
> for clearing the surface, but this method is tedious. An easier way
> could be to allocate a new memory block by using `FT_Memory', copy
> the image data there, free all the cairo resources and set the flag
> `FT_GLYPH_OWN_BITMAP' at `slot->internal->flags'. Now, FreeType can
> easily handle freeing this memory whenever it wants to.
>
> This approach works fine as long as the client program is linking to
> FreeType statically. Turns out, the functions `ft_mem_alloc' and
> `ft_mem_free' don't make it to the dynamic symbol table and thus are
> not accessible to my rendering port if the client program is linking
> dynamically. This is simply because `ft_mem_*' functions are not
> exported and cannot be used from outside.
>
> Any ideas on what I should do here? Is it a bad idea to get access
> to `ft_mem_*' functions from inside my ports?
>
> Regards,
>
> Moazin
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG: `librsvg' based port functional now

[Behdad Esfahbod]

Hi Moazin,

That looks great.

You shouldn't be using global state though.  The state should be held by
FT_Library and passed to init/fini as well as the renderer functions.

On Tue, Jul 2, 2019 at 10:03 PM Moazin Khatri 
wrote:

> Hi Werner and Toshiya,
>
> While using resvg to render glyphs from SVG documents which contain
> multiple glyphs, I observed some clipping issues. Ultimately, I realized
> the
> problem was with `resvg'. So I started work on a `librsvg' based port.
> That
> is functional now and can be found here
> .
> This one doesn't have those
> clipping issues and works fine with SVG documents that contain multiple
> glyphs.
>
> I will probably debug the issue more later on and if I am sure it's a
> problem
> with `resvg', I will report it to the devs of `resvg'.
>
> Werner, the sluggishness you mentioned earlier, I observed that it doesn't
> occur in this `librsvg' port. Turns out, it was occurring because I was
> linking
> against a `debug' build of `resvg' not the `release'  build. Changing
> that,
> removed the sluggishness and everything works super fast now. :)
> Still looking at how the caching might be extended to  work with OT-SVG
> is a good idea and stays in my list. :)
>
> Regards,
> Moazin
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Modification in FT_Gzip_Uncompress

[Behdad Esfahbod]

Note that OT-SVG only allows gzip-wrapper compressed documents, not
zlib-wrapped.

On Sat, Jun 8, 2019 at 1:57 AM Moazin Khatri  wrote:

> Hi,
>
> In OpenType fonts, SVG documents can be either in plain text or gzip
> encoded.
>
> While writing the code to read these documents I looked for a function
> which could do gzip decoding inside FreeType. That's when I found
> `FT_Gzip_Uncompress'. Using it, I realized it didn't work as expected and
> returned errors.
>
> After using zlib in a separate program on the same data I figured out the
> problem. Zlib data can be encoded with both `gzip' and `zlib' encoded
> wrapper. AFAIK, by default, it looks for only `zlib' wrapper. The current
> call to `inflateInit2' is:
>
> 749|  err = inflateInit2( , MAX_WBITS );
>>
>>
> `MAX_WBITS' is 15. Thus, it only looks for `zlib' wrapper and in case of
> gzip compressed SVGs, returns error when `inflate' is called. The fix is to
> replace it with:
>
> 749|  err = inflateInit2( , MAX_WBITS|32 );
>>
>>
> This enables both `gzip' and `zlib' decoding with automatic header
> detection. Solving my problem.
>
> I am quoting the relevant section from zlib's manual for reference. Can be
> seen here :
>
> windowBits can also be greater than 15 for optional gzip decoding. Add 32
>> to windowBits to enable zlib and gzip decoding with automatic header
>> detection, or add 16 to decode only the gzip format (the zlib format will
>> return a Z_DATA_ERROR).
>
>
> This solves it for me and I HOPE this won't cause cause any previous code
> relying on `FT_Gzip_Uncompress' to fail. Let me know if there are easy
> tests to check that.
>
> Let me know if this is the right change and can also be made in master
> later on, meaning I can rely on it. :)
>
> Moazin
>
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Pixel Differences after 2ea511eed8 and 7a81b63abc2b3

[Behdad Esfahbod]

Alexei,

I don't know about others on the list.  But I find the linear algebra /
bezier discussion very interesting and I'm happy to discuss those.

The new algorithm is pretty simple, yes.  BTW, I wonder if the 1/8th of
pixel tolerance is what's causing this:

  https://lists.cairographics.org/archives/cairo/2008-May/014149.html

1/8th of a pixel sounds too large of an error for a 256-level rasterizer.

b

On Fri, May 24, 2019 at 9:42 AM Alexei Podtelezhnikov 
wrote:

> > Similarly, if FreeType had performance tracking bots it would be easy to
> follow the benefits of a performance improvement and such decisions would
> be come more data driven.
>
> Dominik,
>
> You point is well taken, but benchmarking FreeType is hard even
> considering that rendering is the bottleneck. This is because there is
> often too many moving parts, too many simple and incredibly complex
> fonts to choose from, too many use cases. No single number is probably
> sufficient, instead I look at each individual components: flattening a
> single Bezier segment (cubic and conic separately), rendering a line,
> composing the image, etc. I actually use 'perf to see how the shares
> of a function of interest changes. This is incredibly tedious work. I
> do use "ftbench -b c" too to get an integral number (it is not like we
> do not have anything, we do have ftbench). You are welcome to hit me
> over the head if "ftbench -b c" deteriorates, so that your complains
> are also data driven.
>
> Case in point: Bezier bisections have not been touched in more than 10
> years. I myself could not imagine that I would improve them by 20-30%.
> Then I spent an evening tweaking them and probably (just probably)
> found something that makes sense in C and performs well. Do you think
> I would find somebody to talk to meanwhile? Do you think this is more
> interesting than discussing SVG? I doubt. This is quite boring. I only
> like to work on FreeType rendering because it is so reach in linear
> algebra, not because I enjoy programming. Bezier flattening is about
> linear algebra. Shall we go into the weeds? Most algorithms that you
> can find are all correct subject to a certain threshold condition. I
> think what I committed is incredibly simple computationally, so that
> it will be hard to beat in performance. It is again my gut feeling
> with a couple of percents in performance improvement.
>
> The previous algorithms survived for 6-10 years. I don't think this is
> too frequent to rebase your incredibly useful testing framework.
>
> Alexei
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] The criterion for comparing SVG Rendering libraries

[Behdad Esfahbod]

On Tue, May 14, 2019 at 11:42 PM Werner LEMBERG  wrote:

>
> > Realistically, not many fonts combine multiple glyphs into the same
> > SVG documents, for obvious reasons of workflow: fonts are built out
> > of a collection of standalone SVGs much more often than hand-curated
> > SVG documents representing multiple glyphs each.
>
> Not having had a closer look at your SVG Emoji font, so I wonder
> whether it contains such `hand-curated' stuff for testing purposes...
> Otherwise, do you know test examples for that?  Eventually, this
> should all be added to a proper test suite.
>

No.  The Noto font is bunch of separate SVGs.

I don't know of such a hand-crafted SVG font.  I'm sure someone has a demo
somewhere... Firefox was working on one at some point.

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] The criterion for comparing SVG Rendering libraries

[Behdad Esfahbod]

On Tue, May 14, 2019 at 11:24 PM Werner LEMBERG  wrote:

>
> > If you read the OT-SVG table spec, multiple glyphs can refer to the
> > same SVG document.  Then for a glyph eg. 1234, client is expected to
> > render the element with id "glyph1234" in the referenced SVG
> > document.
>
> OK, thanks.  Since my SVG knowledge is virtually zero, the following
> question might be silly: Do you think that this kind of `caching'
> should be done on the FreeType side or on the SVG side?
>

That's interesting question. Ideally font is memory-mapped and FreeType
just returns a pointer to the SVG document, so there's no copying
involved.  Then the client can do any caching if they deem necessary.  But
given the way FreeType works, that might not be possible.  I suggest
returning a copy of the string as FreeType probably have to, but possibly
expose API that shows which glyph ranges share the same document.

In HarfBuzz, we have a type hb_blob_t to encapsulate chunk of bytes and do
the memory-ownership management on it.  So we just return a hb_blob_t per
glyph, and client can, if it chooses to, peek at the pointer to the data
the blob points to to do the caching.  So, HarfBuzz SVG API is really just:

HB_EXTERN hb_bool_t hb_ot_color_has_svg (hb_face_t *face); HB_EXTERN
hb_blob_t * hb_ot_color_glyph_reference_svg (hb_face_t *face,
hb_codepoint_t glyph);
https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-ot-color.h#L124

I think something as simple as that is a good start.  Realistically, not
many fonts combine multiple glyphs into the same SVG documents, for obvious
reasons of workflow: fonts are built out of a collection of standalone SVGs
much more often than hand-curated SVG documents representing multiple
glyphs each.

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] The criterion for comparing SVG Rendering libraries

[Behdad Esfahbod]

On Tue, May 14, 2019 at 9:42 AM Werner LEMBERG  wrote:

>
> >> Could you tell me more about "all the current energye is going in
> >> the wrong direction"?  Do you think "spending much energy for the
> >> discussion which is not so much important"?  Or, do you think
> >> "trying to implement something in wrong design"?
> >
> > (Replying to your and Werner's message here together.)
> >
> > For example, API design can be discussed.
>
> This will certainly come.
>
> > Also another requirement of the SVG renderer that I didn't see
> > mentioned at all: should be able to render a specific element
> > (referred to by identifier) of the SVG instead of whole SVG.
>
> Please elaborate and give an example.  What part of OpenType's `SVG'
> table documentation are you referring to?
>

If you read the OT-SVG table spec, multiple glyphs can refer to the same
SVG document.  Then for a glyph eg. 1234, client is expected to render the
element with id "glyph1234" in the referenced SVG document.


> >   https://github.com/behdad/noto-color-emoji-svg-test
>
> Thanks a lot!
>
>
>Werner
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] The criterion for comparing SVG Rendering libraries

[Behdad Esfahbod]

On Tue, May 14, 2019 at 9:17 AM suzuki toshiya 
wrote:

> Dear Behdad,
>
> Alexei wrote:
> > Whatever external SVG renderer you choose, please use FT_Renderer
> facility to hook it up with FreeType instead of creating a set of SVG
> specific functions: an SVG glyph should be tagged as FT_GLYPH_FORMAT_SVG,
> which is then picked up by the dedicated SVG FT_Renderer with hooks to
> external library. The SVG support can be enabled/disabled using the
> renderer modules, say "svg-ot", in modules.cfg.
>
> Behdad wrote:
> > EXACTLY.  Also why I think, and said, that all the current energy is
> going in the wrong direction.
>
> Could you tell me more about "all the current energye is going in the wrong
> direction"?
> Do you think "spending much energy for the discussion which is not so much
> important"?
> Or, do you think "trying to implement something in wrong design"?
>

(Replying to your and Werner's message here together.)

For example, API design can be discussed.

Also another requirement of the SVG renderer that I didn't see mentioned at
all: should be able to render a specific element (referred to by
identifier) of the SVG instead of whole SVG.


> Great!  Is this available from a repository?

I just put it here now:

  https://github.com/behdad/noto-color-emoji-svg-test

The Svgz variant still doesn't work in Firefox.  I'm surprised.  Just wrote
to Jonathan Kew to ask.  I vaguely remember he implemented that.

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] The criterion for comparing SVG Rendering libraries

[Behdad Esfahbod]

On Tue, May 14, 2019 at 8:37 AM Alexei Podtelezhnikov 
wrote:

>
> > 3. *How much work to do make it work with FreeType*: Does it need a
>> >C API wrapper?
>>
>> Yes.
>
>
> Whatever external SVG renderer you choose, please use FT_Renderer facility
> to hook it up with FreeType instead of creating a set of SVG specific
> functions: an SVG glyph should be tagged as FT_GLYPH_FORMAT_SVG, which is
> then picked up by the dedicated SVG FT_Renderer with hooks to external
> library. The SVG support can be enabled/disabled using the renderer
> modules, say "svg-ot", in modules.cfg.
>

EXACTLY.  Also why I think, and said, that all the current energy is going
in the wrong direction.

Work can already be started implementing the SVG table and
FT_GLYPH_FORMAT_SVG and then tested with any of the renderers before being
any need to settle on one.

Also, I have a version of NotoColorEmoji in SVG.  I think at least checking
how that renders with various renderers should also be part of the criteria
for picking a default or recommending.


>
> https://www.freetype.org/freetype2/docs/reference/ft2-module_management.html
>
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [ft] Three GSoC projects for FreeType

[Behdad Esfahbod]

On Wed, May 8, 2019 at 10:19 PM Werner LEMBERG  wrote:

>
> >> It's not completely off the table, but it seems to me that
> >> `svgnative' is preferable.
> >
> > Given that we want a pluggable renderer, the whole discussion is
> > moot.
>
> It's not moot at all IMHO.  I want to have a default that has as few
> dependencies as possible and is flexible.  And `svgnative' seems like
> an ideal candidate for that.  If people are going to use something
> else, they have to override the default.
>
> Of course, the forthcoming callback API should be generic enough to
> allow a broad range of libraries – please follow Moazin's attempts in
> the next few months and chime in in case you think something is
> missing or done in a non-optimal way.
>

To me, the plugging part is 20 lines of code.  The bulk of the project is
independent of the renderer.



> > For pangocairo, we're going to want to plug librsvg.
>
> You want that because you are going to use the `librsvg' (within
> pangocairo) for other purposes also?
>

Yes, librsvg is already is used to render SVG icons, etc through gdkpixbuf.

b
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [ft] Three GSoC projects for FreeType

[Behdad Esfahbod]

On Tue, May 7, 2019 at 9:46 AM Werner LEMBERG  wrote:

>
> > What happened to the resvg (Rust library) idea?
>
> It's not completely off the table, but it seems to me that `svgnative'
> is preferable.
>

Given that we want a pluggable renderer, the whole discussion is moot.  For
pangocairo, we're going to want to plug librsvg.  So maybe that can be
worked out.


> > Also, note that the small SVG Native comes at a cost that it doesn't
> > support much...
>
> This remark I don't understand.  What exactly do you mean with
> `doesn't support much'?  Please explain.  As far as I can see,
> `svgnative' will *exactly* cover the SVG stuff allowed in OpenType.
> Do we need more?
>

Not really.  First, SVG Native is still being designed.  Nothing is set in
stone.  As it is, it doesn't have many features.  Patterns are out.
Filters are out.  Anything other than simple gradients is out basically...
See my comment and Dirk's response at the bottom of this article:


https://medium.com/adobetech/svg-native-open-sourcing-svg-native-viewer-988125328a07

Now, some would claim that that's exactly what is allowed in OpenType.
Again, that's what we will be discussing to make happen.  As it happens,
there is no relationship between OpenType and SVG Native.

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [ft] Three GSoC projects for FreeType

[Behdad Esfahbod]

What happened to the resvg (Rust library) idea?  At any rate, I agree SVG
renderrer should be pluggable by client and not fixed in FreeType.

Also, note that the small SVG Native comes at a cost that it doesn't
support much...

On Tue, May 7, 2019 at 8:27 AM  wrote:

> On Tue, May 07, 2019 at 07:53:22PM +0500, Moazin Khatri wrote:
> > > I wonder if a re-implementation is a good idea.
>
> Since it's to get rid of a c++ toolchain dep, it's always a good idea.
> Maintenance will occur naturally if svg based fonts get significant
> traction.
> The good new is that it seems to be a small subset of svg, specific to font
> rendering.
>
> For the svg renderer, the tiny svg renderer from the netsurf browser should
> really be really audited: how much to add to get "font svg" rendering
> (already
> based on cairo).
>
> regards,
>
> --
> Sylvain
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Savannah downloads broken?

[Behdad Esfahbod]

On Thu, Apr 4, 2019, 12:40 AM Werner LEMBERG  wrote:

>
> Hello Behdad!
>
>
> > When trying to download this:
> >
> >   http://download.savannah.gnu.org/freetype/freetype-2.9.tar.bz2
> >
> > which is linked from:
> >
> >   http://download.savannah.gnu.org/releases/freetype/
>
> Is it?


It was getting respected there, yes.

  On this very page I get
>
>   http://download.savannah.gnu.org/releases/freetype/freetype-2.9.tar.bz2
>
> as the link, and this works just fine.  Maybe a HTTP caching error
> somewhere?
>

Works for me now as well.  I first noticed this because our bots were
failing, but it also reproduced from my laptop.  I think Savannah people
fixed it.

Thanks

>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Savannah downloads broken?

[Behdad Esfahbod]

When trying to download this:

  http://download.savannah.gnu.org/freetype/freetype-2.9.tar.bz2

which is linked from:

  http://download.savannah.gnu.org/releases/freetype/

I get a 404.  Our HarfBuzz CI bots are hitting this.  Any idea?

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] what FT_Color

[Behdad Esfahbod]

Skia has been rendering color fonts to billions of devices for over five
years now, based on existing FreeType.  Patches existed for cairo for the
same time and were finally integrated last year.  This idea that something
big in FreeType has happened re color recently sounds detached from reality
of FreeType clients IMO. Specifically I advise against adding features
without having potential major users first.

On Sun, Mar 3, 2019 at 3:19 AM Nikolaus Waxweiler 
wrote:

> I haven’t followed the color glyph discussion closely, but I think this is
> a question to ask the people who are going to implement color font
> rendering, i.e. Skia, Qt, Cairo, WebKit(?). I don’t think they read this
> mailing list.
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Potential Timing Side-channel in Freetype Library

[Behdad Esfahbod]

On Tue, Feb 19, 2019 at 2:27 AM Werner LEMBERG  wrote:

>
> > We're a group of researchers from University of California
> > Riverside. We recently discovered that the outline processing (font
> > translation/decomposition) subroutine in the Freetype version 2.9.1
> > takes variable amount of time depending on which character is to be
> > rendered.  As a result, an unprivileged attacker could potentially
> > utilize flush+reload cache side-channel attack to measure the
> > execution time of said subroutine to infer user input.  Although in
> > most applications, this subroutine is performed only once for each
> > character of the same font type, we found that for some applications
> > this is enough for an attacker to extract sensitive information.
> >
> > For detailed information please refer to our paper in the link
> > below. We would be very happy to work with you to address this
> > issue. Please let us know what you think.
> >
> > https://www.cs.ucr.edu/~zhiyunq/pub/ndss19_cache_keystrokes.pdf
>
> Thanks for bringing this to our attention.  Glyph rendering is a time
> consuming process; making the rendering time of all glyphs equal is
> definitely a no-go IMHO, since it would make FreeType far too slow.
>
> What I could imagine, however, is to add some random fuzz so that the
> rendering time varies by an additional value N (with N to be set by
> the library user).  I can imagine that this would sufficiently reduce
> the repeatability, making it much harder to execute the attack as
> described in your paper.
>

I don't think that belongs in FreeType.

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Behdad Esfahbod]

Fully agree. Thanks Nikolaus and Ben.

On Mon, Feb 4, 2019, 3:06 PM Ben Wagner  wrote:

> So, to summarize, the new behavior is sTypo (if UseTypoMetrics), then hhea
> (if not 0), then sTypo (if not 0), then usWin. This is now consistent
> across all fonts; variable fonts do not have a different fallback order.
> Variable fonts will apply the MVAR deltas to whichever metrics were picked.
>
> This explains the behavior change seen when rolling this into Chromium (
> https://chromium-review.googlesource.com/c/chromium/src/+/1452712 ) and
> the change to the cff2 font (
> https://test-results.appspot.com/data/layout_results/linux-blink-rel/6261/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html
> ). This is AdobeVFPrototype.otf (checked into blink's test resources) and
> it does not set the UseTypoMetrics bit, so we're using the FreeType
> computed metrics. The MVAR for this font only has 'stro' and 'xhgt', so no
> variable adjustments. What has changed is that FreeType now provides the
> hhea metrics instead of the sTypo metrics since UseTypoMetrics isn't set.
>
> Overall I like this change, this behavior is easier to reason about. This
> particular font didn't ask nicely to use the sTypo metrics, and it's
> probably a good thing to keep it that way to keep testing this case.
>
>
>
> Le lun. 4 févr. 2019 à 01:46, Werner LEMBERG  a écrit :
>
>> > Done, pushed and fingers crossed.
>>
>> Thanks!
>>
>>
>> Werner
>>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Behdad Esfahbod]

I must confess I haven't fully followed your reports.

On Wed, Jan 30, 2019 at 4:49 PM Nikolaus Waxweiler 
wrote:

> Then what should happen is that everything is just shifted, no? E.g. Qt
> does this:
>
> https://i.postimg.cc/ZR3x17mw/Bildschirmfoto-vom-2019-01-31-00-09-31.png
> https://i.postimg.cc/PJjQhWrT/Bildschirmfoto-vom-2019-01-31-00-09-56.png
>
> Text becomes compressed.
> Am Do, 31. Jan, 2019 um 12:38 A. M. schrieb Behdad Esfahbod
> :
> > That's what line-gap is: gap between consecutive lines.  There is no
> > line before the first line, and as such, no gap.
>
>

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Behdad Esfahbod]

That's what line-gap is: gap between consecutive lines.  There is no line
before the first line, and as such, no gap.

On Wed, Jan 30, 2019 at 4:37 PM Nikolaus Waxweiler 
wrote:

> Even more testing.
>
> ftview and Qt actually do the same GTK does: they don't add the line
> gap to the top, so text fields look compressed when the
> USE_TYPO_METRICS bit is set and typo asc+desc is smaller than hhea
> asc+desc. I'm not sure this is supposed to happen?! Didn't test MVAR
> modification.
>
> Firefox and Chromium disregard FT_Face's ascender, descender and height
> attributes and use either hhea (I think; no USE_TYPO_METRICS) or typo
> metrics (USE_TYPO_METRICS), modifying typo metrics and the FT_Face
> attributes through the MVAR table therefore has no effect unless the
> USE_TYPO_METRICS bit is set.
>
> The document body of a new text file in LibreOffice Writer 6.1.4.2
> stays the same  regardless of bit so I think LO Writer is doing it
> right. It doesn't support VFs though so I can't test MVAR modifications.
>
> Behdad, I'm not completely sure of typo deltas in MVAR modifying the
> currently active metrics. Given that the hhea set is basically a legacy
> value and is probably taller spaced than the typo metrics, so we might
> end up doing things the designer didn't intend? What FF/Chromium do
> strikes me as saner, i.e. writing typo metrics to FT_Face
> ascender/descender/height when USE_TYPO_METRICS is set :/
>
> Otherwise, I'd say unless anyone has objections, I think we can merge
> the branch.
>
>

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Logging library proposal

[Behdad Esfahbod]

On Tue, Jan 22, 2019 at 11:47 AM Werner LEMBERG  wrote:

>
> Of course.  Only if some preprocessor macros are defined at configure
> time, this feature is available – I won't change that.  In other
> words, it will stay as a developer-only feature.


Right.  Which makes using en external library overkill.


>   Irrespective of
> that, good debugging messages are *invaluable* and thus worth to be
> improved.
>
>
> Werner
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Logging library proposal

[Behdad Esfahbod]

Werner,

Please don't use an external library.  Logging in FreeType is for
developers only, and some parts maybe for font designers.  Clients who just
want to render text don't need the logging capabilities.  Just keep it
simple.

On Mon, Jan 21, 2019 at 4:35 PM Yash Khasbage 
wrote:

> Hi
> I want to work on your project titled "Replace FreeType's tracing and
> debugging facilities with an external logging library". You have mentioned
> that there are platforms where stderr is not accessible. Can you give me an
> example of such a platform?
> Anyways, a simple solution to an inaccessible stderr is to print log
> messages directly into a file. Our code will work independently of whether
> stderr is accessible or not. There is a library "zlog" -
> https://github.com/HardySimpson/zlog supporting logging into a file. It
> is similar to log4j and log4cpp. It has pretty good features. Its
> documentation is good, it is well maintained and is licensed under
> LGPL-v2.1. A windows version is also available for it. According to me,
> zlog will serve the purpose.
> Can you elaborate on what are your exact targets in this project? Does the
> project only aim for "platforms with inaccessible stderr"? Can you explain
> me some difficulties we may face? If you feel zlog is suitable for this
> project, I want to start contributing to freetype in gsoc as well.
> Thank You
> Yash
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Behdad Esfahbod]

On Sat, Dec 22, 2018 at 11:23 AM Nikolaus Waxweiler 
wrote:

>
> > The thinking within the working group was that no one uses win
> > metrics, so we didn't encode their variations.  Indeed, the only time
> > one uses them these days is if typo and hhea metrics are not set...
>
> >
> But MVAR tags for win metrics exist?
>
> https://docs.microsoft.com/en-us/typography/opentype/spec/mvar#value-tags
>
> 'hcla'  horizontal clipping ascent  OS/2.usWinAscent
> 'hcld'  horizontal clipping descent OS/2.usWinDescent
>
> Or are they specifically for clipping avoidance and should never modify
> line metrics?


You are right.  Those are for clipping on older Windows systems.  Only if
there's no usable line size in hhea or typo ones should one use win.


> Then the code should be removed anyway from the MVAR
> apply function. I see in the HB code you linked that you use the typo
> metrics if the typo bit is set and hhea metrics otherwise. I can find
> no mention of win* metrics in the codebase. Should FreeType behave
> similarly? I.e.
>





> 1. If OS/2 table exists and typo bit is on, use typo metrics
> 2. Otherwise, use hhea metrics
> 3. Unless they are zero, then use typo metrics. If they are zero as
> well, so be it.
> (4. Always ignore win metrics)
>
> The comment given in sfobjs.c:1662 says that some ARIALNB.ttf has typo
> metrics set to zero. So, not sure about 4., maybe only for static fonts?
>
> I'm in a bit of a bind with Cantarell, as I already released a version
> that ships with GNOME and does not have the typo bit set. Grr. I guess
> I need to look into how to make GTK or whatever add line gap somewhere
> or change the metrics around...
>
>

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Behdad Esfahbod]

On Sat, Dec 22, 2018 at 8:43 AM Nikolaus Waxweiler 
wrote:

> > There's also the question of whether MVAR tags should apply to
> > whatever was used for ascent/descent.  I think yes.  And I'll
> > implement that in HB.
>
> What would you do when
>
> 1. the typo metrics are modified by the MVAR table
>

If Typo exists, that's what MVAR tags are applied to.


> 2. win metrics are modified
> 3. both are modified
>

The thinking within the working group was that no one uses win metrics, so
we didn't encode their variations.  Indeed, the only time one uses them
these days is if typo and hhea metrics are not set...

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Behdad Esfahbod]

On Thu, Dec 20, 2018 at 5:32 AM Werner LEMBERG  wrote:

>
> > I just tested the static and variable fonts in macOS 10.14 TextEdit.
> > For the static instances, it presumably takes the hhea metrics, for
> > the VF, it always takes typo metrics. (It also adds the line gap at
> > the bottom, making text look weird, but maybe that's because the
> > layout logic is broken.)
>
> Thanks for testing!
>
> > So that would speak in favor of always using either typo or win
> > metrics for variable fonts, even for the default outlines?
>
> Behdad?
>

Umm.  I suggest FreeType be changed to respect OS/2 useTypoMetrics bit.
This is my attempt in HB:

https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-ot-hmtx-table.hh#L194

and then use same logic for VF and non-VF.  There's also the question of
whether MVAR tags should apply to whatever was used for ascent/descent.  I
think yes.  And I'll implement that in HB.



> > Or maybe this is really the fault of GTK/Pango/something because it
> > loads the default outline instead of the default instance, which
> > would yield the correct metrics?
>
> This is certainly the most convenient solution for me since I have
> nothing to do on the FreeType side :-)
>

GTK/Pango/Cairo just call into FreeType for metrics.

I'm confused.  What does "default outline" vs "default instance" mean?


> Your question, however, is a fundamental one: Shall a VF font be
> always treated as VF, or is the `VFness' an optional feature?
>
>
> Werner
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Behdad Esfahbod]

On Thu, Dec 20, 2018 at 6:02 AM Nikolaus Waxweiler 
wrote:

> > This is certainly the most convenient solution for me since I have
> > nothing to do on the FreeType side :-)
>
> (As an aside, GTK/Pango seem to make the same mistake as TextEdit then,
> putting the line gap at the bottom instead of on both sides or something,
> so this would still look wrong even if FT would default to typo metrics for
> VFs)
>

lineGap should be put in between two neighboring lines only.



> > Your question, however, is a fundamental one: Shall a VF font be
> > always treated as VF, or is the `VFness' an optional feature?
>
> I'd say the primary purpose of a VF is to be a VF, it is only optionally
> so for applications that don't know what a VF is. You'd think that using
> the hhea metrics for the default outlines would make sense in that case,
> but this still presents a corner case if the applications increases in
> smartness and suddenly the same font has different metrics 樂
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] color framework

[Behdad Esfahbod]

On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov 
wrote:

> On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov
>  wrote:
> > > Alexei, I think we miscommunicate.
> >
> > I struggle to get your attention to FT_Glyph_To_Bitmap.
>
> I just discovered that, while ignoring the FT_Glyph abstraction in the
> current implementation, we also disregard FreeType caching system, see
> FTC_ImageCache_Lookup. This is just lovely but please continue your
> arguments against fire-walling FT_Render_Glyph from accessing FT_Face.
>

I don't understand what you mean; if you're being sarcastic or not.  But
FreeType caching system does not solve any problem for the systems I know.
It's at best useful only for small clients for single-threaded use.

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] color framework

[Behdad Esfahbod]

On Tue, Dec 18, 2018 at 5:35 AM Werner LEMBERG  wrote:

>
> >> FreeType is about to make a major leap into color rendering.
> >
> > Is it?  Color rendering was the news before variable-fonts were
> > news.  So 2013.  The world has moved on.
>
> You completely misunderstood.  Alexei talks about FreeType, not about
> the latest font news.
>

FreeType has been rendering color fonts on over a billion devices since
2015 or so.  I still think the whatever FreeType is adding now is minor in
comparison to that.  At any rate, doesn't matter.


> >> It is possible to make it right while keeping rendering separate.
> >> The current solution is way to specific to COLR/CPAL.  What if CFF
> >> comes up with something different?  I agree that current FT_Color
> >> is too simple.  We can add an index field there to indicate layers
> >> explicitly or even reference gradient colors of SVG fonts.
> >
> > You cannot take just outline and gradients out of SVG and shove it
> > into a model you design now.  It's either SVG, or plain outlines.
> > Don't try representing SVG in some other form unless you are
> > volunteering to do it all.
>
> We won't do SVG.  However, having a good representation of contours
> with color layers is quite useful.
>
> > I actually found the FT_Renderer abstraction useful to let
> > toolkits / applications install an SVG renderer on an FT_Library to
> > render SVG color fonts.  I like to see that as a possibility.
>
> Let's see whether someone is interested in this.  What about making
>
>   Add SVG support
>
> a GSoC project?  :-)
>
> >> > Not really.  It's not like glyphslot and face can be used
> >> > separately.
> >>
> >> That's, in fact, the biggest problem with FreeType API: that one
> >> cannot use FT_Face from multiple threads at the same time, because
> >> all uses of it use the embedded glyphslot.
> >>
> >> Full circle: is FT_Glyph or rather FT_OutlineGlyph, extracted and
> >> detached by FT_Get_Glyph, of any use?  It is stripped down to bare
> >> bones though.
>
> `FT_Glyph' is not, but Alexei wants to improve `FT_OutlineGlyph'.
>
> > It would be so much easier for FreeType clients, specially toolkits
> > and frameworks, if FT_Face, FT_Size, and FT_GlyphSlot were all
> > separate.  Ie. one FT_Face could be used with multiple FT_Size's
> > simultaneously, and multiple FT_Face/FT_Size pairs could be used to
> > load glyphs into different FT_GlyphSlot's simultaneously.
> >
> > That is, for example, similar to how hb_face_t, hb_font_t, and
> > hb_buffer_t are modeled.  FreeType goes most of the way there, but
> > alas, ties one FT_GlyphSlot and one FT_Size into the FT_Face, making
> > it totally unusable for any sophisticated sharing scenario.  If you
> > can fix *that*, I'd be indebted to you eternally!
>
> AFAICS, this can't be fixed.  The only solution I see is to define a
> new API.
>

Obviously.  What's wrong with defining new API?

-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] color framework

[Behdad Esfahbod]

On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov 
wrote:

> FT_Render_Glyph used to be democratic. The renderers were chosen based
> on the match between the glyph format and the rendering mode. The only
> way to keep it this way is either FT_RENDER_MODE_BGRA or
> FT_GLYPH_FORMAT_LAYERED.


FORMAT_LAYERED was how I have had originally imagined this implemented (and
started even).  However, that still makes the GlyphSlot require Face to
render, right?  Not that I think that's wrong...

The reason I like the current implementation in master is this:
FORMAT_LAYERED itself is not enough.  We would need a new flag to signal
loading layers, since without that new flag, we should just load the
requested glyph id.  NO_RECURSE cannot be used for this, since that is
already used to handle composite glyphs, which the glyph in question might
be.



> You know that I tried both. We are
> introducing new way or rendering (for FreeType) I do not see a problem
> with being open and transparent about it.
>



-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Behdad Esfahbod]

On Tue, Dec 18, 2018 at 11:43 AM Nikolaus Waxweiler 
wrote:

> Thanks Alexei for chiming in at
> https://github.com/googlei18n/fontmake/issues/492#issuecomment-448249543.
>
> > The following seems to be different: hhea does not seem to be used in
> VF. Compare and decide which one is correct.
> >
> >
> https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/truetype/ttgxvar.c#n1365
> >
> https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sfnt/sfobjs.c#n1670
>
> The OpenType spec says nothing variation specific about hhea/typo/win
> metrics, except that hhea vmetrics don't seem to be supported by the
> `MVAR` in that only win and typo metrics have `MVAR` tags:
>

The reasoning for that was that varfonts should set OS/2 useTypoMetrics bit
on and as such only one set of values need variation.  I would say if that
bit is off then the respective MVAR tags should be applied to hhea values.



> -
> https://docs.microsoft.com/en-us/typography/opentype/spec/hhea#39hhea39-table-and-opentype-font-variations
> -
> https://docs.microsoft.com/en-us/typography/opentype/spec/mvar#value-tags
> -
> https://docs.microsoft.com/en-us/typography/opentype/spec/os2#stypoascender
> -
> https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswinascent
>
> Regarding ascender, descender and height calculation in sfobjs.c and
> ttgxvar.c: the math seems to be the same:
>
> - hhea: ascender 983, descender -217, line gap 0 -> total height 1200 fU
> - typo: ascender 739, descender -217, line gap 244 -> total height 1200 fU
> - win: ascender 983, descender 217, line gap 0 -> total height 1200 fU
>
> For static fonts, FT uses hhea metrics: `root->height = root->ascender
> - root->descender + face->horizontal.Line_Gap;` or `983 - (- 217) + 0
> = 1200`
> For instances, it uses typo metrics: `root->height = root->ascender -
> root->descender + face->os2.sTypoLineGap;` or `739 - (-217) + 244 =
> 1200`
>
> Will look into this deeper later.
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>


-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] color framework

[Behdad Esfahbod]

On Sat, Dec 15, 2018 at 11:10 PM Alexei Podtelezhnikov 
wrote:

>
> FreeType is about to make a major leap into color rendering.


Is it?  Color rendering was the news before variable-fonts were news.  So
2013.  The world has moved on.


> It is
> possible to make it right while keeping rendering separate. The
> current solution is way to specific to COLR/CPAL. What if CFF comes up
> with something different? I agree that current FT_Color is too simple.
> We can add an index field there to indicate layers explicitly or even
> reference gradient colors of SVG fonts.
>

You cannot take just outline and gradients out of SVG and shove it into a
model you design now.  It's either SVG, or plain outlines.  Don't try
representing SVG in some other form unless you are volunteering to do it
all.

I actually found the FT_Renderer abstraction useful to let toolkits /
applications install an SVG renderer on an FT_Library to render SVG color
fonts.  I like to see that as a possibility.


> >> The choice is between a hack and a proper implementation.
> >
> > Not really.  It's not like glyphslot and face can be used separately.
> That's, in fact, the biggest problem with FreeType API: that one cannot use
> FT_Face from multiple threads at the same time, because all uses of it use
> the embedded glyphslot.
>
> Full circle: is FT_Glyph or rather FT_OutlineGlyph, extracted and
> detached by FT_Get_Glyph, of any use?  It is stripped down to bare
> bones though.
>
> Thank you for your understanding of my position. Really.
>

I think you misunderstood my intentions upthread.  When I asked what's
wrong with current color framework, I really meant it.  And when I said as
long as cairo and Chrome work I don't care, I also meant it :).  All I'm
asking is, if FT_LOAD_COLOR is passed to FT_Load_Glyph() then color bitmap
be rendered.   How it trickles down the abstractions and machinery into
render, you can change.

Since I brought up FT_Face vs FT_GlyphSlot issue, let me put it in writing:

It would be so much easier for FreeType clients, specially toolkits and
frameworks, if FT_Face, FT_Size, and FT_GlyphSlot were all separate.  Ie.
one FT_Face could be used with multiple FT_Size's simultaneously, and
multiple FT_Face/FT_Size pairs could be used to load glyphs into different
FT_GlyphSlot's simultaneously.

That is, for example, similar to how hb_face_t, hb_font_t, and hb_buffer_t
are modeled.  FreeType goes most of the way there, but alas, ties one
FT_GlyphSlot and one FT_Size into the FT_Face, making it totally unusable
for any sophisticated sharing scenario.  If you can fix *that*, I'd be
indebted to you eternally!

Cheers,
b
-- 
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel