Re: Creating a FreeType GitLab merge request

[David Saltzman]

Done

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

> Sounds good; I'll look at walking over the feature list for 'kern'
> features when I get a chance and push an update. (That may not be today, as
> I'll need to do other work).
>
> On Tue, Jan 23, 2024 at 10:45 AM Behdad Esfahbod 
> wrote:
>
>> 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 <
>>> ht...@users.sourceforge.net> 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 

Re: Creating a FreeType GitLab merge request

[David Saltzman]

Sounds good; I'll look at walking over the feature list for 'kern' features
when I get a chance and push an update. (That may not be today, as I'll
need to do other work).

On Tue, Jan 23, 2024 at 10:45 AM Behdad Esfahbod  wrote:

> 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 <
>> ht...@users.sourceforge.net> 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 

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: Creating a FreeType GitLab merge request

[David Saltzman]

>
> 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 
> 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: Creating a FreeType GitLab merge request

[Hin-Tak Leung]

 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 
 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  
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: Creating a FreeType GitLab merge request

[David Saltzman]

>
> 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 
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: Creating a FreeType GitLab merge request

[Alexei Podtelezhnikov]

> 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: Creating a FreeType GitLab merge request

[Hin-Tak Leung]

 FWIW, this seems to duplicate functionality in harfbuzz, and also a mere 
subset, for that matter? It is rather a dead-end development direction? I think 
the question is, at what point do you stop? AFAIK, this kind of functionality 
was removed quite intentionally from freetype and moved to harfbuzz about 2 
decades ago.
Granted, harfbuzz is a bit too big these days - but what you are proposing 
sounds a lot like creating a harfbuzz-lite, a lighter weight version of 
harfbuzz, to be honest. For your intended usage, maybe that's what you should 
do - submit a series of trims, rip-outs, removals and opt-outs to remove 
functionality from harfbuzz to slim it down to GPOS-based kerning only... 
that's perhaps a more worthwhile work.
FWIW, it is also not unheard of to maintain a semi-permanent set of patches for 
freetype deemed unsuitable for upstreaming. Yes, I am questioning putting this 
in freetype at all, since it was removed two decades ago and became the 
beginning of harfbuzz, as far as I understand. It is going backwards by two 
decades...
On Monday, 22 January 2024 at 17:08:40 GMT, David Saltzman 
 wrote:  
 
 Thanks Alexei. I found the issue on the wiki; apparently new accounts have 
forking disabled by default, and new users need to file user verification 
tickets to get verified before being able to fork. I did that, and now forking 
succeeds.
I filed a merge request here: 
https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/315. Is there 
a way I should add reviewers or open any needed discussion or anything else for 
the merge request?
David
On Fri, Jan 19, 2024 at 7:25 PM Alexei Podtelezhnikov  
wrote:

Understandably, you cannot edit files in place. You need an account on
gitlab.freedesktop.org and [fork] FreeType, which has been done 114
times already.
Alternatively, send your patch here with a good description.

Alexei

On Fri, Jan 19, 2024 at 9:03 PM David Saltzman  wrote:
>
> Hi,
>
> I'd like to submit a feature to FreeType. https://freetype.org/developer.html 
> recommends doing so via GitLab merge requests. But when I tried pushing to a 
> branch on the command line, git said "ERROR: You are not allowed to push code 
> to this project." Then I tried clicking edit->web IDE, and that said I can't 
> edit files in that project and I need to create a new fork. But creating a 
> fork from that link fails, and the fork button is greyed out on the main page.
>
> So do I need to join or be added to some access list, or are there other 
> tricks for permissions or tools to use to submit GitLab merge requests?
>
> Thanks,
> David



-- 
Alexei A. Podtelezhnikov, PhD

  

Re: Creating a FreeType GitLab merge request

[David Saltzman]

Thanks Alexei. I found the issue on the wiki
;
apparently new accounts have forking disabled by default, and new users
need to file user verification tickets to get verified before being able to
fork. I did that, and now forking succeeds.

I filed a merge request here:
https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/315. Is
there a way I should add reviewers or open any needed discussion or
anything else for the merge request?

David

On Fri, Jan 19, 2024 at 7:25 PM Alexei Podtelezhnikov 
wrote:

> Understandably, you cannot edit files in place. You need an account on
> gitlab.freedesktop.org and [fork] FreeType, which has been done 114
> times already.
> Alternatively, send your patch here with a good description.
>
> Alexei
>
> On Fri, Jan 19, 2024 at 9:03 PM David Saltzman 
> wrote:
> >
> > Hi,
> >
> > I'd like to submit a feature to FreeType.
> https://freetype.org/developer.html recommends doing so via GitLab merge
> requests. But when I tried pushing to a branch on the command line, git
> said "ERROR: You are not allowed to push code to this project." Then I
> tried clicking edit->web IDE, and that said I can't edit files in that
> project and I need to create a new fork. But creating a fork from that link
> fails, and the fork button is greyed out on the main page.
> >
> > So do I need to join or be added to some access list, or are there other
> tricks for permissions or tools to use to submit GitLab merge requests?
> >
> > Thanks,
> > David
>
>
>
> --
> Alexei A. Podtelezhnikov, PhD
>

Alternative Re: Creating a FreeType GitLab merge request

[Hin-Tak Leung]

 Yes, I think I had an fd gitlab account ages ago but after not using it for a 
while it got disabled and I am having problem re-enabling it again. Anyway, I 
have never used the fork/pull/merge facility on gitlab with freetype ever, and 
it has always been the old-fashion way - how git was originally used with the 
Linux kernel:
You just do your own work in your own local repo, and after playing with your 
own local branches, merges, tidying up, etc, do:
    git format-patch origin/main..
This exports everything between upstream (origin/main) and your current work 
(.. , short hand for "..HEAD", difference to the current state of your current 
branch) as a series of plain text patches. Send those as e-mail attachments to 
the right people, that's all. Or, if they are simple enough, just inline them 
in a email body.
The old-fashioned usage of git includes using "git send-email" with those 
patches too, which inline them as a series of e-mails...


On Saturday, 20 January 2024 at 16:36:45 GMT, Alan Coopersmith 
 wrote:  
 
 On 1/19/24 19:25, Alexei Podtelezhnikov wrote:
> Understandably, you cannot edit files in place. You need an account on
> gitlab.freedesktop.org and [fork] FreeType, which has been done 114
> times already.

And because of restrictions implemented last year on the gitlab server
to cut down on spam & abuse, you'll also need to request the ability
to make forks with your new account:

https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home

-- 
        -Alan Coopersmith-                alan.coopersm...@oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris


  

Re: Creating a FreeType GitLab merge request

[Alan Coopersmith]

On 1/19/24 19:25, Alexei Podtelezhnikov wrote:

Understandably, you cannot edit files in place. You need an account on
gitlab.freedesktop.org and [fork] FreeType, which has been done 114
times already.


And because of restrictions implemented last year on the gitlab server
to cut down on spam & abuse, you'll also need to request the ability
to make forks with your new account:

https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Re: Creating a FreeType GitLab merge request

[Alexei Podtelezhnikov]

Understandably, you cannot edit files in place. You need an account on
gitlab.freedesktop.org and [fork] FreeType, which has been done 114
times already.
Alternatively, send your patch here with a good description.

Alexei

On Fri, Jan 19, 2024 at 9:03 PM David Saltzman  wrote:
>
> Hi,
>
> I'd like to submit a feature to FreeType. https://freetype.org/developer.html 
> recommends doing so via GitLab merge requests. But when I tried pushing to a 
> branch on the command line, git said "ERROR: You are not allowed to push code 
> to this project." Then I tried clicking edit->web IDE, and that said I can't 
> edit files in that project and I need to create a new fork. But creating a 
> fork from that link fails, and the fork button is greyed out on the main page.
>
> So do I need to join or be added to some access list, or are there other 
> tricks for permissions or tools to use to submit GitLab merge requests?
>
> Thanks,
> David



-- 
Alexei A. Podtelezhnikov, PhD