Re: GSOC 2024 - Proposal

[Werner LEMBERG]

Hello Mahaveer,


thanks for your proposal.  However, can you please tell us what
exactly you want to improve?  FreeType is a glyph rendering library;
usually, it takes a *glyph index* (and not a Unicode character) as an
input and returns a bitmap rendering of a glyph's outline.  Handling
Unicode-encoded input strings *must* be done in a higher-level library
like 'HarfBuzz' – we are definitely not going to add such
capabilities.

Only a very small part, namely the auto-hinter, processes a font's
Unicode character map table to gather more knowledge for hinting
glyphs.  Improving this part was a GSoC project of the last year (see
https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/316)


Werner

Re: GSOC Contribution

[Werner LEMBERG]

Hello Claire,


> I would like to become a contributor to your organization. How do I
> become a contributor?

FreeType is a library to render glyphs of a font, written in the
C programming language.  Becoming a 'contributor' essentially means
that you have experience with handling such a library, doing some
programming work.  You might have a look at

  https://freetype.org/gsoc.html

that lists some idea – if you have more suggestions, please write to
the 'freetype-devel' mailing list.


 Werner

Re: GSoC 2024 idea list is not released.

[suzuki toshiya]

Dear Akhilesh,

Please find the discussion after Nitish's similar post:

https://lists.nongnu.org/archive/html/freetype-devel/2024-02/msg0.html

Regards,
mpsuzuki

On 2024/02/23 3:00, Akhilesh yadav wrote:

Hello,
I hope this message finds you  well. I noticed that Free Type is participating 
in GSoC 2024, but the idea list for 2024 has not been released yet. Could you 
please provide some insight into this? I am keen on contributing and have the 
capability to propose my own project idea if necessary. Moreover, I am 
confident in my ability to work on the project with minimal guidance from a 
mentor.
If this approach aligns with your expectations, please let me know.

Thank you,
Akhilesh

Re: GSoC has ended

[Ahmet Göksu]

Hello,
I wanted to ping one more time about my previous mail.
I would be so happy if I have a chance to get a recommendation letter about the 
time we spend together and the job I did.

Best,
Goksu
goksu.in
On Nov 15, 2023 at 16:02 +0300, ahmetsgo...@icloud.com , wrote:
>
> additionally, a recommendation letter from you, either as a pdf file or on 
> LinkedIn, would be incredibly valuable for my burgeoning career in computer 
> science.

Re: GSoC has ended

[ahmetsgo...@icloud.com]

Hello!

 I thoroughly enjoyed collaborating with you over the summer on our project. I 
would greatly appreciate your feedback on the aspects I handled well and areas 
where I could improve. Additionally, a recommendation letter from you, either 
as a pdf file or on LinkedIn, would be incredibly valuable for my burgeoning 
career in computer science. Your insights have always been enlightening, and 
I'm eager to continue learning from you. I also hope to remain involved with 
Freetype and look forward to future collaborations with or without GSoC :)

Best,
Goksu
goksu.in
On Nov 15, 2023 at 6:00 AM +0100, Werner LEMBERG , wrote:
>
> Folks,
>
>
> GSoC 2023 is over; a few days ago the last project has finished – all
> FreeType students have passed :-)
>
> We had three projects:
>
> * Ahmet's code to improve 'ftbench' so that it can emit benchmarking
> test reports:
>
> https://gitlab.freedesktop.org/freetype/freetype/-/tree/gsoc-2023-ahmet-final
>
> * Anurag's code to port 'font-rs', an alternative rendering engine, to
> FreeType and compare it to the built-in rasterizer; and to convert
> some parts of FreeType's documentation to Markdown
>
> https://docs.google.com/document/d/14me6L4HEMnjBVFwOCjaBayRjQym-WK_RQuOJt7A3pCY/edit
> https://gitlab.freedesktop.org/freetype/freetype/-/tree/gsoc-anurag-2023-final
> https://gitlab.freedesktop.org/freetype/freetype/-/tree/gsoc-anurag-2023-docs-final
>
> * Craig's auto-hinter code to implement a 'capabilities database' so
> that glyphs like the 'tilde' accent stay legible at smaller sizes:
>
> https://gitlab.freedesktop.org/freetype/freetype/-/tree/gsoc-craig-2023-final
>
> I want to say thank you to Ahmet, Anurag, and Craig – it's great to
> have people like you who want to help improve FreeType – and wish you
> all the best for your future careers!
>
>
> Werner

Re: [GSoC][Introducing Myself]

[Werner LEMBERG]

Hello Kostya,


welcome to FreeType!

> I just wanted to introduce myself. My name is Kostya Farber.  I am a
> data engineer, I work at Aviva and am based in London.  I have a
> strong passion and love for software development and technology in
> general.

Nice!

> I have been learning c for a while now, mostly writing systems
> programs in a Linux environment and generally writing small programs
> for fun.  I want to further develop my skills in this area.  The
> reason I am interested in this project particularly, is because I
> love fonts and typography.  I have always dreamed of somehow being
> involved or contributing in this space, and I think this is a great
> opportunity to do so!

It would be great if you could contribute to FreeType.

> I am conscious that I do have a full time job, but seeing as Google
> has announced the opportunity for non-students [...]

Unfortunately, GSoC explicitly discourages participating organizations
from taking 'such' non-students.  To quote a very recent e-mail from
Stephanie Taylor, the GSoC program manager (on the non-public 'Google
Summer of Code Mentors List'):

  GSoC is intended for beginners to open source software development,
  it is not intended for experienced software engineering
  professionals.

  The spirit of the program is to welcome new contributors to open
  source software development.

  GSoC is not a way to help professional software engineers gain more
  experience in software development or earn additional money.

In other words, we welcome any contribution from you to FreeType, and
we would be as supportive as with GSoC students, but this can't happen
within the framework of GSoC itself.  Sorry.


Werner

Re: GSoC 2023

[Werner LEMBERG]

>> 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.

Thanks, this idea is worthwhile to pursue with ...

> I apologize. I forgot about ftbench.

... `ftbench` :-) In other words, it would be helpful to set up a
Makefile target to do some standardized `ftbench` calls so that it is
possible to compare a baseline (say, a released version) against the
current git version.

Below is the text I've added to FreeType's GSoC page.


Werner


==


Integrate ftbench into FreeType's build structure(s)

The `ftbench` demo program is a small tool that benchmarks the
performance of various FreeType library functions.  The aim of this
project is to integrate it into FreeType's build system(s) so that the
timings of a *baseline* (for example, a released version) can be
easily compared with the timings of the current git version.
Eventually, the results should be integrated into FreeType's CI as
provided by gitlab.

There are many approaches possible to accomplish the project.  For
example, the raw results emitted by `ftbench` could be post-processed
by a script to produce a nice-looking HTML page.  Another possibility
is to modify the `ftbench` program directly to emit HTML code.

Difficulty: medium.  Size: 175h/350h.  Requirements: C, Unix build
tools, meson, HTML.  Potential mentors: Werner Lemberg, Alexei
Podtelezhnikov, Toshiya Suzuki (FreeType).

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
>>
>

Re: [GSoC] Status of font-rs port

[Anurag Thakur]

Hello Werner,

I have converted the rasterizer to use fixed point, will post a more elaborate 
status report once I get SIMD working with fixed point, but here are the 
highlights:

1. Fixed point calculation is notably faster.
2. I have analysed fontdue, and it doesn't seem to have any significant 
difference in the rasterizer algorithm, just some minor improvements which I am 
in the process of porting over.
3. Added comments and cleaned up the code a bit. More documentation work in 
progress.
4. I am also testing the renderer on a variety of fonts and have found some 
issues, (specifically when the outlines overflow the glyph width).

Will post more testing details and perf numbers in a report soon.

Regards
Anurag


From: Werner LEMBERG 
Sent: Tuesday, 11 October, 2022, 11:17 AM
To: Anurag Thakur 
Cc: apodt...@gmail.com ; freetype-devel@nongnu.org 

Subject: Re: [GSoC] Status of font-rs port


Hello Anurag,


what's the current state of your project?  Please tell us what's going
on :-)


Werner

Re: [GSoC] Status of font-rs port

[Werner LEMBERG]

Hello Anurag,


what's the current state of your project?  Please tell us what's going
on :-)


Werner

Re: GSoC project `ftinspect` now in master

[Alexei Podtelezhnikov]

Congratulations!

Alexei

> On Oct 3, 2022, at 12:41, Charlie Jiang  wrote:
> 
> Hi Werner and other folks,
> 
> It's extremely delightful to hear that my project has been merged into 
> `master`!
> 
> I would express my deep gratitude to all who lent me a hand during the 
> project, especially Werner, Alexei, and mpsuzuki. Without your precious help, 
> the GSoC project would never have been completed.
> 
> It was a great experience to work with folks in the FreeType community, and 
> I'm determined to further contribute to the open source communities including 
> FreeType.
> 
> Cheers,
> Charlie Jiang
> 


OpenPGP_signature
Description: Binary data

Re: GSoC project `ftinspect` now in master

[Charlie Jiang]

Hi Werner and other folks,

It's extremely delightful to hear that my project has been merged into 
`master`!


I would express my deep gratitude to all who lent me a hand during the 
project, especially Werner, Alexei, and mpsuzuki. Without your precious 
help, the GSoC project would never have been completed.


It was a great experience to work with folks in the FreeType community, 
and I'm determined to further contribute to the open source communities 
including FreeType.


Cheers,
Charlie Jiang



OpenPGP_signature
Description: OpenPGP digital signature

RE: [GSoC] Status of font-rs port

[Anurag Thakur]

> Do you mind continuing this discussion as an issue on GitLab?

Created issue https://gitlab.freedesktop.org/freetype/freetype/-/issues/1184 
for continuing discussion

From: Alexei Podtelezhnikov 
Sent: Friday, September 16, 2022 9:59 PM
To: Anurag Thakur 
Cc: freetype-devel@nongnu.org
Subject: Re: [GSoC] Status of font-rs port


Anurag


> Can also look at some more challenging fonts with very fine curves, eg, 
> Windows' KUNSTLER.TTF

I tested it, and the rasterizer output is almost identical.

Curiously, for this font, the dense rasterizer is faster even till 200-300 ppem 
font size

This is definitely because smooth is constrained by memory and has to restart 
(see longjmp) with narrower bands to handle the job. It looks like one restart 
for each glyph approximately.


Relevant files attached.

Do you mind continuing this discussion as an issue on GitLab?

A

Re: [GSoC] Status of font-rs port

[Alexei Podtelezhnikov]

Anurag 

> > Can also look at some more challenging fonts with very fine curves, eg, 
> > Windows' KUNSTLER.TTF
> 
> I tested it, and the rasterizer output is almost identical.
>  
> Curiously, for this font, the dense rasterizer is faster even till 200-300 
> ppem font size

This is definitely because smooth is constrained by memory and has to restart 
(see longjmp) with narrower bands to handle the job. It looks like one restart 
for each glyph approximately.

> Relevant files attached.

Do you mind continuing this discussion as an issue on GitLab? 

A

Re: [GSoC] Status of font-rs port

[Alexei Podtelezhnikov]

Anurag,

> 1 and 2 have been fixed, but monochrome output still crashes ftgrid for the 
> dense rasterizer

Smooth returns Cannot_Render_Glyph for mono, thus passing the job to b/w 
raster. Dense should do the same.

A.

Re: [GSoC] Status of font-rs port

[Werner LEMBERG]

> 1 and 2 have been fixed, but monochrome output still crashes ftgrid
> for the dense rasterizer

A good start would be a backtrace...


Werner

RE: [GSoC] Status of font-rs port

[Anurag Thakur]

Thanks for the quick fix!

1 and 2 have been fixed, but monochrome output still crashes ftgrid for the 
dense rasterizer

I’ll investigate it and report

Regards
Anurag

From: Alexei Podtelezhnikov 
Sent: Friday, September 16, 2022 9:16 AM
To: Anurag Thakur 
Cc: freetype-devel@nongnu.org
Subject: Re: [GSoC] Status of font-rs port



On Thu, Sep 15, 2022 at 5:53 PM Anurag Thakur 
mailto:anurag105cse...@bpitindia.edu.in>> 
wrote:
List of bugs I have encountered:
1. Ftgrid produces weird output and crashes at large sizes(~170ppem)
2. The inverted bitmap pitch causes rendering differences (can be seen in the 
“Q” letter of the ftview output)
3. Ftgrid crashes when selecting monochrome output

Should be fixed by a005039b.
Thanks for the report.

Re: [GSoC] Status of font-rs port

[Alexei Podtelezhnikov]

> Also, if there is some way of viewing the libc function name instead of 
> address, that would be helpful.

I am sure these are malloc, free, memset, memcpy, etc. As the size
increases they contribute more and more.
Still, dense_raster_render must be spending some time just walking
around the huge matrix.  If you press Enter and Annotate,
you will see the hottest lines.

RE: [GSoC] Status of font-rs port

[Anurag Thakur]

Hello Alexei,

> Can you confirm that straight line drawing still takes most of the time with 
> the dense rastrerizer?

Running perf on ftbench reports:

10ppem:

  22.20%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_render_line
  15.37%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_render_quadratic
   6.01%  lt-ftbench  libfreetype.so.6.18.3  [.] TT_Load_Simple_Glyph
   5.76%  lt-ftbench  libfreetype.so.6.18.3  [.] FT_Outline_Get_CBox
   3.79%  lt-ftbench  libfreetype.so.6.18.3  [.] load_truetype_glyph
   3.22%  ld  libbfd-2.39.so [.] bfd_link_hash_traverse
   2.46%  lt-ftbench  libfreetype.so.6.18.3  [.] FT_Outline_Decompose
   1.23%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_raster_render

100ppem:

  48.12%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_render_line
  18.94%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_raster_render
   9.13%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_render_quadratic
   2.33%  lt-ftbench  libfreetype.so.6.18.3  [.] TT_Load_Simple_Glyph
   2.11%  lt-ftbench  libfreetype.so.6.18.3  [.] FT_Outline_Get_CBox
   1.75%  lt-ftbench  libm.so.6  [.] fminf32x
   1.40%  lt-ftbench  libfreetype.so.6.18.3  [.] load_truetype_glyph
   1.36%  lt-ftbench  libm.so.6  [.] fmaxf32x
   1.10%  lt-ftbench  libfreetype.so.6.18.3  [.] FT_Outline_Decompose

1000ppem:

  70.29%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_raster_render
  10.60%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_render_line
   6.88%  lt-ftbench  libc.so.6  [.] 0x001541c4
   6.29%  lt-ftbench  libc.so.6  [.] 0x001541ce
   1.25%  lt-ftbench  libc.so.6  [.] 0x001541d3
   1.22%  lt-ftbench  libc.so.6  [.] 0x001541c9
   0.68%  lt-ftbench  libfreetype.so.6.18.3  [.] dense_render_quadratic
   0.38%  lt-ftbench  libm.so.6  [.] fminf32x
   0.32%  lt-ftbench  libm.so.6  [.] fmaxf32x

I believe something changes at around 200ppem that causes the rendering time to 
increase dramatically.
Will investigate and report.

Also, if there is some way of viewing the libc function name instead of 
address, that would be helpful.

Regards
Anurag

From: Alexei Podtelezhnikov 
Sent: Friday, September 16, 2022 8:04 AM
To: Anurag Thakur 
Cc: freetype-devel@nongnu.org
Subject: Re: [GSoC] Status of font-rs port


Hi Anurag,

The rasterizer code (including SIMD) has been integrated into the FreeType and 
seems to be working fine,

Comparison images: dense and smooth renderer (outlines and dots disabled)

This is a really nice progress indeed. The images look almost identical. Can 
also look at some more challenging fonts with very fine curves, eg, Windows' 
KUNSTLER.TTF. We need to make sure that both rasterizers are tuned to similar 
quality.

The performance is comparable (sometimes better) to the smooth renderer for 
small font sizes, however it is several times slower for larger sizes

This is really quite stunning. I look forward to further progress. Can you 
confirm that straight line drawing still takes most of the time with the dense 
rastrerizer?

I am thinking of working on the “Direct rendering mode” next. Any pointers 
regarding that would be appreciated.

I am not sure about this one. The whole point of direct mode is to leave the 
canvas allocation to the client. The dense rasterizer defeats this purpose.

And just for reference
List of bugs I have encountered:
1. Ftgrid produces weird output and crashes at large sizes(~170ppem)
2. The inverted bitmap pitch causes rendering differences (can be seen in the 
“Q” letter of the ftview output)

Hmm. Is this only when Q is on the last row? That would be an ftview bug then. 
I do not see any problems with parentheses? Is this 2.12.1 demos?

3. Ftgrid crashes when selecting monochrome output

Do you think this is also a pitch sign bug?

4. [TODO] lcd rendering needs to be implemented

This is either three interlaced bitmaps after shifts, or 3x resolution with 
filtering. You should be able to copy this from smooth.

Best,
Alexei

Re: [GSoC] Status of font-rs port

[Alexei Podtelezhnikov]

On Thu, Sep 15, 2022 at 5:53 PM Anurag Thakur <
anurag105cse...@bpitindia.edu.in> wrote:

> List of bugs I have encountered:
> 1. Ftgrid produces weird output and crashes at large sizes(~170ppem)
>
> 2. The inverted bitmap pitch causes rendering differences (can be seen in
> the “Q” letter of the ftview output)
>
> 3. Ftgrid crashes when selecting monochrome output
>

Should be fixed by *a005039b.*
Thanks for the report.

Re: [GSoC] Status of font-rs port

[Alexei Podtelezhnikov]

Hi Anurag,

The rasterizer code (including SIMD) has been integrated into the FreeType
> and seems to be working fine,
>
> Comparison images: dense and smooth renderer (outlines and dots disabled)
>

This is a really nice progress indeed. The images look almost identical.
Can also look at some more challenging fonts with very fine curves, eg,
Windows' KUNSTLER.TTF. We need to make sure that both rasterizers are tuned
to similar quality.


> The performance is comparable (sometimes better) to the smooth renderer
> for small font sizes, however it is several times slower for larger sizes
>

This is really quite stunning. I look forward to further progress. Can you
confirm that straight line drawing still takes most of the time with the
dense rastrerizer?


> I am thinking of working on the “Direct rendering mode” next. Any pointers
> regarding that would be appreciated.
>

I am not sure about this one. The whole point of direct mode is to leave
the canvas allocation to the client. The dense rasterizer defeats this
purpose.


> And just for reference
>
> List of bugs I have encountered:
> 1. Ftgrid produces weird output and crashes at large sizes(~170ppem)
>
> 2. The inverted bitmap pitch causes rendering differences (can be seen in
> the “Q” letter of the ftview output)
>

Hmm. Is this only when Q is on the last row? That would be an ftview bug
then. I do not see any problems with parentheses? Is this 2.12.1 demos?


3. Ftgrid crashes when selecting monochrome output


Do you think this is also a pitch sign bug?


4. [TODO] lcd rendering needs to be implemented

This is either three interlaced bitmaps after shifts, or 3x resolution with
filtering. You should be able to copy this from smooth.

Best,
Alexei

Re: [GSoC] Merge Request - to master or to a seperate branch?

[Werner LEMBERG]

> If I set up a parallel personal branch (gsoc-2022-chariri)
> cherry-picking my contributions, while new commits are still being
> merged, would it work?  The parallel branch would serve the purpose
> of proof-of-contribution and it will be a logically organized single
> line.

This should work.  However, I'm not sure whether this works out as
intended: I tend to walk over a branch again and again (using `git
rebase -i`) until all commits are in a good shape.  Cherry-picking
prevents that approach; modifying commits at that stage would be very
confusing.

> The main concern is that, if the dev branch isn’t actively merged,
> it may end up being a huge merge-conflict hell at the end of the
> GSoC.

Why do you think that?  Simply do `git rebase master` from time to
time to fix this.

> Also, the code quality may lose control and end up like the
> previous GSoC project about ftinspect :( .

Believe me, the problems with the previous `ftinspect` project were
definitely *not* git issues :-)

>> BTW, it might help setting up CI support for 'freetype-demos', and
>> inparticular for `ftinspect`.  Can you do that?
> 
> If it’s only for |ftinspect|, it’s fine since it requires few
> dependencies.  Which platforms are needed?

Ideally the same platforms as used in FreeType's `.gitlab-ci.yml`.


Werner

Re: [GSoC] Merge Request - to master or to a seperate branch?

[Charlie Jiang]

My conclusion: If it weren't for GSoC, your approach would be justfine.  
However, for the sake of having your code at one single place Iask you to use 
one or more working branches, with a cleaned-upreference branch holding 
logically organized commits as the final GSoCtarget.


I see. If I set up a parallel personal branch (gsoc-2022-chariri) 
cherry-picking my contributions, while new commits are still being 
merged, would it work? The parallel branch would serve the purpose of 
proof-of-contribution and it will be a logically organized single line.


The main concern is that, if the dev branch isn’t actively merged, it 
may end up being a huge merge-conflict hell at the end of the GSoC. 
Also, the code quality may lose control and end up like the previous 
GSoC project about ftinspect :( .



BTW, it might help setting up CI support for 'freetype-demos', and inparticular 
for `ftinspect`.  Can you do that?


If it’s only for |ftinspect|, it’s fine since it requires few 
dependencies. Which platforms are needed?


Cheers,
Charlie

​

Re: [GSoC] Merge Request - to master or to a seperate branch?

[Werner LEMBERG]

>> If you want to submit general changes to FreeType please submit
>> MRs.  However, for your ftinspect GSoC stuff you should push to a
>> personal branch (or even branches, if necessary) of the upstream
>> repositories *without* MRs.  In your personal branch(es) you can go
>> wild – no need for forking:-)
> 
> Well... As is mentioned in the proposal, my original idea was to
> have the code merged from my dev branch to master immediately after
> one functional is completed (more like the workflow I experienced in
> some other projects) ... So it would be a lot of branches and MRs
> (now those temporary branches can be directly pushed to the upstream
> repo).  I'm actively rebasing and re-organizing my commits so
> they're ready to be merged into master.
> 
> The main reasons are: 1) MR provides a good tool for code reviewing
> and progress tracking.  With GitLab Issues, it would be a lot more
> convenient to discuss project details.  2) Continuous merging
> ensures a better overall code quality because this would require the
> quality to be always ready to be merged.
> 
> However, I'm OK with the personal branch , if you insist :) .

Here's the thing: At the end of GSoC, you have to write a report that
references your code.  This means that people not directly involved
with FreeType should be able to understand your contributions.  While
FreeType is a rather slowly moving project, it still moves.  If
everything of your code is in a single, final branch, you have a
single reference.  Otherwise, you get a bunch of references to the git
repository, probably interspersed with other commits that change code
related to `ftinspect`, too.

My conclusion: If it weren't for GSoC, your approach would be just
fine.  However, for the sake of having your code at one single place I
ask you to use one or more working branches, with a cleaned-up
reference branch holding logically organized commits as the final GSoC
target.

BTW, it might help setting up CI support for 'freetype-demos', and in
particular for `ftinspect`.  Can you do that?


Werner

Re: [GSoC] Merge Request - to master or to a seperate branch?

[Charlie Jiang]

Hello Werner,


If you want to submit general changes to FreeType please submit MRs.
However, for your ftinspect GSoC stuff you should push to a personal
branch (or even branches, if necessary) of the upstream repositories
*without*  MRs.  In your personal branch(es) you can go wild – no need
for forking:-)


Well... As is mentioned in the proposal, my original idea was to have 
the code merged from my dev branch to master immediately after one 
functional is completed (more like the workflow I experienced in some 
other projects) ... So it would be a lot of branches and MRs (now those 
temporary branches can be directly pushed to the upstream repo). I'm 
actively rebasing and re-organizing my commits so they're ready to be 
merged into master.


The main reasons are: 1) MR provides a good tool for code reviewing and 
progress tracking. With GitLab Issues, it would be a lot more convenient 
to discuss project details. 2) Continuous merging ensures a better 
overall code quality because this would require the quality to be always 
ready to be merged.


However, I'm OK with the personal branch , if you insist :) .

Cheers,
Charlie

Re: [GSoC] Merge Request - to master or to a seperate branch?

[Werner LEMBERG]

Hello Charlie,


> I'm going to make my first commit for the GSoC.

Great!

> It's a minor change - CMakeLists.txt for ftinspect. I've pushed the
> commit to my forked repo on the GitLab.  However, where should I
> create MR to?  Should I create a MR from my master branch to the
> master branch of freetype/freetype-demos repo, or to a seperate
> branch in the official repo (as I noticed there're branches for
> other GSoC students in the official repo)?

I've just added you as a developer to the FreeType repositories.

If you want to submit general changes to FreeType please submit MRs.
However, for your ftinspect GSoC stuff you should push to a personal
branch (or even branches, if necessary) of the upstream repositories
*without* MRs.  In your personal branch(es) you can go wild – no need
for forking :-)

At the end of the GSoC period you should eventually consolidate your
commits into logical chunks in a branch called something like
'GSoC-2022-charlie', which you can then reference in your final
report.


Werner

Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines

[Alexei Podtelezhnikov]

> On Apr 19, 2022, at 22:36, Matsumura, George  wrote:
> 
> From what I could glean, rusttype uses the rust library ab_glyph_rasterizer 
> for its rendering, which in turn uses the algorithm used by stb_truetype, 
> which is described here:
> https://nothings.org/gamedev/rasterize/

which references LibArt, which is also the basis of FreeType algorithm. I would 
focus on something with legitimate claims of beating FreeType performance, not 
just rust for the sake of rust.

A

Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines

[Matsumura, George]

Greetings Anurag,

From what I could glean, rusttype uses the rust library 
ab_glyph_rasterizer for its rendering, which in turn uses the algorithm 
used by stb_truetype, which is described here:

https://nothings.org/gamedev/rasterize/

I hope this helps.

Regards,
George

On 4/19/22 15:00, Anurag Thakur wrote:
NOTICE: This message was sent from outside Ohio University. Please use 
caution when clicking links or opening attachments in this message.
Indeed! RustType looks like a good candidate for evaluation.  It also 
appears to be using a different algorithm for rasterization, I'll read 
more about it.


Regards
Anurag

On 13-Apr-2022 12:18 AM, Bermler  wrote:

rustType might be a good place to look at as well


https://github.com/redox-os/rusttype





On Tue, Apr 12, 2022 at 12:20 PM, Anurag Thakur
mailto:anurag105cse...@bpitindia.edu.in>> wrote:

Hello everyone!

I am Anurag Thakur, a first-year undergraduate student pursuing
Computer Science.

I am interested in contributing to the project *“**Integrate
FreeType with alternative rendering engines” *as part of GSOC
2022 and have been learning about it for some time.

Reading through the mailing list discussions and building on the
work of other contributors, I have been successful in creating
prototype renderer module for FreeType that

is based on the font-rs rasteriser. The renderer module is
written in C and is very barebones at the moment, since I wanted
to discuss with the community and wait for an official approval for

my proposal before investing too much effort in any particular
direction.

Since the parsing improvements of font-rs don’t completely apply
to FreeType due to the requirement of hinting etc., I have been
focusing on the rasteriser improvements, i.e., a dense data
structure

for storing the accumulation buffer, that is better suited for SIMD.

Having briefly studied the renderers mentioned at FreeType’s
GSOC page, I believe the best course of action would be to first
properly integrate a font-rs based renderer in FreeType

and then working on optimizing the implementation by studying
the code of font-go and fontdue.

I am currently studying the code of Fontdue and since it started
as a fork of font-rs I hope integration will not be too tough.

Pathfinder seems to be very different from the other renderers,
I need to study more about it, and will try to determine the
best way to integrate it with FreeType.

I am also working on a way to properly benchmark the different
implementations and would appreciate any pointers regarding it.

I would be grateful if the community could point me towards
other font-rendering implementations that could be of interest
to FreeType. Any research project or prototype that

can bring performance improvements is welcome.

Any other insights or guidance regarding this project would be
greatly appreciated.

I have submitted my draft proposal to the GSOC website, and
humbly request the mentors to take a look at it and provide
feedback.


Regards

Anurag

Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines

[Anurag Thakur]

Indeed! RustType looks like a good candidate for evaluation.  It also appears 
to be using a different algorithm for rasterization, I'll read more about it.

Regards
Anurag

On 13-Apr-2022 12:18 AM, Bermler  wrote:
rustType might be a good place to look at as well


https://github.com/redox-os/rusttype



On Tue, Apr 12, 2022 at 12:20 PM, Anurag Thakur 
mailto:anurag105cse...@bpitindia.edu.in>> 
wrote:

Hello everyone!



I am Anurag Thakur, a first-year undergraduate student pursuing Computer 
Science.

I am interested in contributing to the project “Integrate FreeType with 
alternative rendering engines” as part of GSOC 2022 and have been learning 
about it for some time.



Reading through the mailing list discussions and building on the work of other 
contributors, I have been successful in creating prototype renderer module for 
FreeType that

is based on the font-rs rasteriser. The renderer module is written in C and is 
very barebones at the moment, since I wanted to discuss with the community and 
wait for an official approval for

my proposal before investing too much effort in any particular direction.



Since the parsing improvements of font-rs don’t completely apply to FreeType 
due to the requirement of hinting etc., I have been focusing on the rasteriser 
improvements, i.e., a dense data structure

for storing the accumulation buffer, that is better suited for SIMD.



Having briefly studied the renderers mentioned at FreeType’s GSOC page, I 
believe the best course of action would be to first properly integrate a 
font-rs based renderer in FreeType

and then working on optimizing the implementation by studying the code of 
font-go and fontdue.



I am currently studying the code of Fontdue and since it started as a fork of 
font-rs I hope integration will not be too tough.

Pathfinder seems to be very different from the other renderers, I need to study 
more about it, and will try to determine the best way to integrate it with 
FreeType.



I am also working on a way to properly benchmark the different implementations 
and would appreciate any pointers regarding it.



I would be grateful if the community could point me towards other 
font-rendering implementations that could be of interest to FreeType. Any 
research project or prototype that

can bring performance improvements is welcome.

Any other insights or guidance regarding this project would be greatly 
appreciated.



I have submitted my draft proposal to the GSOC website, and humbly request the 
mentors to take a look at it and provide feedback.


Regards

Anurag

Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines

[Anurag Thakur]

Hello Alexei,


> Do you actually
> plan to port the code to the modules or just link?

As mentioned in my proposal, the code will be ported to C, most likely as a new 
renderer module in the FreeType source.

> or if you are actually
> planning to do them all, not this summer but eventually. I would
> however ask that you put something in your proposal.

The plan is to investigate which renderers are to be ported, and then 
completely implement atleast 1 of them as a renderer module in FreeType during 
GSoC. More implementations can be done depending on tine, and even after GSoC.

Regards
Anurag


On 14-Apr-2022 7:35 AM, Alexei Podtelezhnikov  wrote:
On Tue, Apr 12, 2022 at 1:09 PM Anurag Thakur
 wrote:
>
> Having briefly studied the renderers mentioned at FreeType’s GSOC page, I 
> believe the best course of action would be to first properly integrate a 
> font-rs based renderer in FreeType
>
> and then working on optimizing the implementation by studying the code of 
> font-go and fontdue.

Hi Anurag,

To be honest, I do not know whether the alternative renderers should
be a part of FreeType, or a separate project, or a part of the
respective source projects. The module interface is pretty stable and
should not be a maintenance burden in either case. It also depends on
the performance and size of the modules, or if you are actually
planning to do them all, not this summer but eventually. I would
however ask that you put something in your proposal. Do you actually
plan to port the code to the modules or just link? The summer is
short. Even if you succeed with one of them to the point of release
quality, it is good.

Best,
Alexei

Re: GSoC 2022: Alternative Rendering Engines

[Vincent Torri]

On Thu, Apr 14, 2022 at 4:23 AM Alexei Podtelezhnikov
 wrote:
>
> On Tue, Apr 12, 2022 at 9:57 AM Matsumura, George  wrote:
> > The blog post mentions "a large constant factor because it’s doing
> > complicated exact-area calculations for each pixel" as a performance
> > impediment when drawing into the accumulation buffer. If one were
> > willing to settle for fewer gray levels in the resulting image, could
> > something like multisampling be used to eliminate the need for these
> > area calculations entirely, especially given that SIMD is already being
> > used to exploit parallelism? I'm sure there's a reason why this isn't
> > done, but if someone could enlighten me as to exactly why I would highly
> > appreciate it.
>
> There are basically two approaches to rendering: Windows does
> multisampling, the rest of the world integrates. I do not want to make
> any claims about the speed of the either approach. There are claims
> out there that other renderers beat FreeType using parallelism by the
> expected factor equal to the number of CPUs, maybe more, maybe less.So
> we want to see if we can borrow some of those approaches. The main
> reason why FreeType is very careful about adopting alternative
> approaches is ultra-portability of FreeType to pretty much anything
> under the Sun because of pure C89 or C99. The performance non-parallel
> rendering is not bad. Also, you can do parallelism on levels above
> FreeType and outside of its control.

A note about threads on Window: even if the mingw-w64 project provides
a pthread implementation (called winpthread) which could be useful for
multiplatform code, it is known that winpthread is a bit slower than
native Win32 threads. So I would avoid winpthread on Windows.

Vincent Torri

Re: GSoC 2022: Alternative Rendering Engines

[Alexei Podtelezhnikov]

On Tue, Apr 12, 2022 at 9:57 AM Matsumura, George  wrote:
> The blog post mentions "a large constant factor because it’s doing
> complicated exact-area calculations for each pixel" as a performance
> impediment when drawing into the accumulation buffer. If one were
> willing to settle for fewer gray levels in the resulting image, could
> something like multisampling be used to eliminate the need for these
> area calculations entirely, especially given that SIMD is already being
> used to exploit parallelism? I'm sure there's a reason why this isn't
> done, but if someone could enlighten me as to exactly why I would highly
> appreciate it.

There are basically two approaches to rendering: Windows does
multisampling, the rest of the world integrates. I do not want to make
any claims about the speed of the either approach. There are claims
out there that other renderers beat FreeType using parallelism by the
expected factor equal to the number of CPUs, maybe more, maybe less.So
we want to see if we can borrow some of those approaches. The main
reason why FreeType is very careful about adopting alternative
approaches is ultra-portability of FreeType to pretty much anything
under the Sun because of pure C89 or C99. The performance non-parallel
rendering is not bad. Also, you can do parallelism on levels above
FreeType and outside of its control.

Alexei

Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines

[Alexei Podtelezhnikov]

On Tue, Apr 12, 2022 at 1:09 PM Anurag Thakur
 wrote:
>
> Having briefly studied the renderers mentioned at FreeType’s GSOC page, I 
> believe the best course of action would be to first properly integrate a 
> font-rs based renderer in FreeType
>
> and then working on optimizing the implementation by studying the code of 
> font-go and fontdue.

Hi Anurag,

To be honest, I do not know whether the alternative renderers should
be a part of FreeType, or a separate project, or a part of the
respective source projects. The module interface is pretty stable and
should not be a maintenance burden in either case. It also depends on
the performance and size of the modules, or if you are actually
planning to do them all, not this summer but eventually. I would
however ask that you put something in your proposal. Do you actually
plan to port the code to the modules or just link? The summer is
short. Even if you succeed with one of them to the point of release
quality, it is good.

Best,
Alexei

Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines

[Bermler]

rustType might be a good place to look at as well

https://github.com/redox-os/rusttype

On Tue, Apr 12, 2022 at 12:20 PM, Anurag Thakur 
 wrote:

> Hello everyone!
>
> I am Anurag Thakur, a first-year undergraduate student pursuing Computer 
> Science.
>
> I am interested in contributing to the project “Integrate FreeType with 
> alternative rendering engines” as part of GSOC 2022 and have been learning 
> about it for some time.
>
> Reading through the mailing list discussions and building on the work of 
> other contributors, I have been successful in creating prototype renderer 
> module for FreeType that
>
> is based on the font-rs rasteriser. The renderer module is written in C and 
> is very barebones at the moment, since I wanted to discuss with the community 
> and wait for an official approval for
>
> my proposal before investing too much effort in any particular direction.
>
> Since the parsing improvements of font-rs don’t completely apply to FreeType 
> due to the requirement of hinting etc., I have been focusing on the 
> rasteriser improvements, i.e., a dense data structure
>
> for storing the accumulation buffer, that is better suited for SIMD.
>
> Having briefly studied the renderers mentioned at FreeType’s GSOC page, I 
> believe the best course of action would be to first properly integrate a 
> font-rs based renderer in FreeType
>
> and then working on optimizing the implementation by studying the code of 
> font-go and fontdue.
>
> I am currently studying the code of Fontdue and since it started as a fork of 
> font-rs I hope integration will not be too tough.
>
> Pathfinder seems to be very different from the other renderers, I need to 
> study more about it, and will try to determine the best way to integrate it 
> with FreeType.
>
> I am also working on a way to properly benchmark the different 
> implementations and would appreciate any pointers regarding it.
>
> I would be grateful if the community could point me towards other 
> font-rendering implementations that could be of interest to FreeType. Any 
> research project or prototype that
>
> can bring performance improvements is welcome.
>
> Any other insights or guidance regarding this project would be greatly 
> appreciated.
>
> I have submitted my draft proposal to the GSOC website, and humbly request 
> the mentors to take a look at it and provide feedback.
>
> Regards
>
> Anurag

Re: GSoC 2022: Alternative Rendering Engines

[Werner LEMBERG]

Hello George,


> I am an individual who would be interested in the project "Integrate
> FreeType with alternative rendering engines" listed on FreeType's
> GSoC page.

Great to hear!

> There were multiple things in the blog post that the entry linked to
> that I found interesting/had questions about.
>
> The blog post mentions "a large constant factor because it’s doing
> complicated exact-area calculations for each pixel" as a performance
> impediment when drawing into the accumulation buffer.  If one were
> willing to settle for fewer gray levels in the resulting image,
> could something like multisampling be used to eliminate the need for
> these area calculations entirely, especially given that SIMD is
> already being used to exploit parallelism?  I'm sure there's a
> reason why this isn't done, but if someone could enlighten me as to
> exactly why I would highly appreciate it.

I think less than 256 levels of gray are a bad idea.  Regardless of
that, you have to compute the intersection of the glyph outline with
pixels.  Maybe there is a misunderstanding on my side, so please
elaborate.

> I would assume the parsing efficiency improvements mentioned in the
> blog post wouldn't really be applicable to FreeType, as parsing in
> such a way would inhibit more complex intermediate processes such as
> hinting that font-rs doesn't seem to do.  Please correct me if I am
> wrong here.

Fortunately, you are wrong :-) Hinting is always applied to the
outline before it gets rasterized.  In other words, font rendering is
not affected by hinting.

> Would use of SIMD entail an approach like that used by pixman, where
> hand-coded assembly is made for each SIMD instruction set
> extenstion?  If so, which extentions would be pursued.  I personally
> would love to try and learn to write optimized routines in assembly
> with less-used extensions like MMX or PowerPC AltiVec, but I was
> curious as to how relevant these platforms are viewed as.

Mhmm.  Having assembly code in FreeType doesn't enthuse me.  This
would be a last resort for hotspots if low-level C programming doesn't
give enough speed.  The more generic the code, the less hassle we have
to maintain it.

> I apologize for how behind I am in the proposal process. [...]

No problem :-)


Werner

Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines

[Werner LEMBERG]

Hello Anurag,


> I am interested in contributing to the project “Integrate FreeType
> with alternative rendering engines” as part of GSOC 2022 and have
> been learning about it for some time.

Great!

> Reading through the mailing list discussions and building on the
> work of other contributors, I have been successful in creating
> prototype renderer module for FreeType that is based on the font-rs
> rasteriser.  The renderer module is written in C and is very
> barebones at the moment, since I wanted to discuss with the
> community and wait for an official approval for my proposal before
> investing too much effort in any particular direction.

OK.

> Having briefly studied the renderers mentioned at FreeType’s GSOC
> page, I believe the best course of action would be to first properly
> integrate a font-rs based renderer in FreeType and then working on
> optimizing the implementation by studying the code of font-go and
> fontdue.

Such an analysis would be part of the project.

> I am currently studying the code of Fontdue and since it started as
> a fork of font-rs I hope integration will not be too tough.
> Pathfinder seems to be very different from the other renderers, I
> need to study more about it, and will try to determine the best way
> to integrate it with FreeType.

Again, all those details should be part of the project.

> I am also working on a way to properly benchmark the different
> implementations and would appreciate any pointers regarding it.

I think the comparison diagrams in Raph Levien's blog entry on font-rs
page are quite a good start.

> I have submitted my draft proposal to the GSOC website, and humbly
> request the mentors to take a look at it and provide feedback.

Will do so soon.


Werner

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Charlie Jiang]

Hi Werner and Alexei,

I've submitted my very first draft of the proposal and I'll really 
appreciate it if you could give me any comments on that. A few more points:


 * How about the project size? Current I chose "Large", but I don't
   know if it matches my proposal.
 * The time schedule was very roughly planned, so please let me know if
   I wrongly estimated the workload and time required.
 * The E-Mail I used to submit the proposal differs from my commonly
   used E-Mail, does that matter?
 * Also let me know if any more information is needed.

Thanks and cheers,
Charlie Jiang

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Werner LEMBERG]

> [...] when I looked into the GSoC 2019 project completed by another
> student
> (https://gist.github.com/GeVic/75889ae2728f6dee0a490166ff8e2271), I
> noticed:
> 
> 1. He already finished integrating several other tools including
>ftdump, ftstring, ftview and ftlint.  Therefore I wonder how
>should I describe my project?  It seems that I shouldn't describe
>it as making the integration from scratch (factually it looks
>like the work has already been done!).

Simply omit the word 'scratch' :-)

> 2. The code was never merged to master branch.

Yes, it was not really working as expected.

> 3. The code from veeki-gsoc-experimental branch was not compiling. I
>made some minor fix so it compiles against the latest FreeType2
>upstream source.

OK.  Maybe you can re-use some parts of it – this is up to you,
however.

> 4. When I load some large fonts (especially CJK fonts), the
>performance was sub-optimal.  The "All Glyphs" view tooks seconds
>to load.

Yep.  I think this was due to an insufficient understanding of the Qt
toolkit and how to implement a proper GUI for features.

> 5. For unknown reasons, most CJK characters won't render.  Instead,
>white boxes are rendered.

Well...

> 6. The overall user experience and GUI logic can be further
>improved.

Indeed.

> 7. The "Multi View" hasn't been implemented yet - what is this?

Uh, no idea.  What exactly are you referring to?

> Additionally, could I submit my current proposal as draft, so you
> could make some comments for further revising?

Of course, please do so!


Werner

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Charlie Jiang]

Hello Werner and Alexei,

I'm current working on the proposal. However, when I looked into the 
GSoC 2019 project completed by another student 
(https://gist.github.com/GeVic/75889ae2728f6dee0a490166ff8e2271), I noticed:


1. He already finished integrating several other tools including
   ftdump, ftstring, ftview and ftlint. Therefore I wonder how should I
   describe my project? It seems that I shouldn't describe it as making
   the integration from scratch (factually it looks like the work has
   already been done!).
2. The code was never merged to master branch.
3. The code from veeki-gsoc-experimental branch was not compiling. I
   made some minor fix so it compiles against the latest FreeType2
   upstream source.
4. When I load some large fonts (especially CJK fonts), the performance
   was sub-optimal. The "All Glyphs" view tooks seconds to load.
5. For unknown reasons, most CJK characters won't render. Instead,
   white boxes are rendered.
6. The overall user experience and GUI logic can be further improved.
7. The "Multi View" hasn't been implemented yet - what is this?

Additionally, could I submit my current proposal as draft, so you could 
make some comments for further revising?


Cheers,
Charlie Jiang

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Charlie Jiang]

Hi Alexei,

The lightweight demos rely on traditional Windows API and protocols. 
There is no need to adopt them to anything beyond that. It sounds like 
you’re are more interested in ftinspect anyway. There you can borrow 
any suitable functionality.


The reason I'm interested in ftinspect is that I'm more familiar with 
GUI frameworks like Qt. Another reason is that it's the original GSoC 
task. Anyway, I fixed these two issues (See Merge Request !20 and !21).



No. I would imagine ftview and ftgrid only to start.


OK then, maybe a further estimation of workload could help me to decide 
whether to include any other tools. Werner also suggested some tools to 
include.


Cheers,
Charlie Jiang

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Werner LEMBERG]

>> I'm not familiar with text rendering and font processing, therefore
>> I'm refering to FreeType documentations and other online materials.
>> Are those skills considered as prerequisites before I submit my
>> proposal?
>
> Yes.  These are FreeType demos.  We’re not really interested in
> Windows API demos except perhaps for side-by-side comparisons. That
> would be cool actually.

Ha, Alexei says exactly the opposite of what I said :-)

A clarification: 'being familiar with rendering and font processing'
doesn't necessarily mean that you are fluent with such programming.
It's rather that you should get acquainted with the concepts and
technical terms of font technology (ascender, descender, EM square,
etc., etc.) and rasterization (e.g., image blitting).  For example,
the OpenType specification contains some introductory material for the
former that might help.

Or to say it differently: If you can understand (from a conceptional
point of view) what `ftview` and the other demo programs do, you are
on the right track.


Werner

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Werner LEMBERG]

>> Good question, I don't know.  Revising FreeType's build system is
>> another GSoC project:-)
> 
> I saw that project.  It will be optimal if he is willing to help us
> out.  Unfortunately both Visual Studio and CLion don't play very
> well with MesonBuild.  I'm used to use CMake to develop Qt projects
> in VS, but I'm fully open to other options or crafting some new
> solutions :).

Well, if you want to contribute a CMake file, please do so :-)

Seriously: Improving the demo programs should work in an environment
that is friendly to you.  You don't have to use the Meson port.

And thanks for the first two Merge Requests!

>> Ideally yes, allowing `ftinspect` being executed on the command
>> line as a batch program.  Alas, such an approach doesn't work on
>> Windows since on that platform you can't execute a GUI program on
>> the command line.
> 
> Not quite, factually `ftinspect` is current executable on the
> command line on Windows (just like on Linux).  The commandline
> arguments are working as well, so it shouldn't be a problem here.

Oh.  I was mistaken, then.  Good to know, thanks.

> My consideration is the added complexity.

Well, put it at the end of your feature list, then :-)


Werner

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Alexei Podtelezhnikov]

> I've played around with ftgrid and ftview, but not all features of them.
> They directly crash when I press "?" if an IME is enabled (e.g. MS Pinyin 
> Input Method).
> Some keys are not working on Windows (notably arrow keys, maybe related to 
> console-attachment problems)
> The keyboard-based control is not so straightforward (at least for Windows 
> users), and moving towards a fully Qt-based GUI could certainly relieve this. 
> However, I noticed some automation functionalities are present (-k option, 
> and p stroke). Should I consider them in ftinspect project?
The lightweight demos rely on traditional Windows API and protocols. There is 
no need to adopt them to anything beyond that. It sounds like you’re are more 
interested in ftinspect anyway. There you can borrow any suitable functionality.
> There're other tools besides ftgrid and ftview (ftbench, ftchkwd, ftdiff 
> ...). Should I include all of them in ftinspect as well?
No. I would imagine ftview and ftgrid only to start.
> I'm not familiar with text rendering and font processing, therefore I'm 
> refering to FreeType documentations and other online materials. Are those 
> skills considered as prerequisites before I submit my proposal?
Yes. These are FreeType demos. We’re not really interested in Windows API demos 
except perhaps for side-by-side comparisons. That would be cool actually.

Alexei 

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Charlie Jiang]

Hi Vincent,

If migrating the whole SVG part (honestly I didn't dug to find where 
librsvg is used) to ThorVG (seems a little bit heavy) is feasible, then 
it's OK.


However, if we're only rasterizing SVG, I believe there're more light 
libraries available.


Cheers,
Charlie Jiang

在 2022/4/5 18:58, Vincent Torri 写道:

what about looking at ThorVG (https://www.thorvg.org/) ?

Vincent Torri

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Vincent Torri]

On Tue, Apr 5, 2022 at 12:44 PM Charlie Jiang  wrote:
>
> Hello Werner,
>
> Thanks for your quick reply!
>
> > However, a
> > quick search in the internet gives me
> >
> >https://gitlab.gnome.org/GNOME/librsvg/-/tree/main/win32
> >
> > Does this help?  Otherwise, compiling the demo programs without
> > 'librsvg' is fully sufficient for improving the demo programs.
>
> Unfortunately, as the page indicates, Gdk-Pixbuf is required to build
> librsvg from stratch, which is considerably hard (it has even more
> indirect dependencies). However eventually I will sort it out (maybe
> after the whole improvement is completed).

what about looking at ThorVG (https://www.thorvg.org/) ?

Vincent Torri

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Charlie Jiang]

Hello Werner,

Thanks for your quick reply!


However, a
quick search in the internet gives me

   https://gitlab.gnome.org/GNOME/librsvg/-/tree/main/win32

Does this help?  Otherwise, compiling the demo programs without
'librsvg' is fully sufficient for improving the demo programs.


Unfortunately, as the page indicates, Gdk-Pixbuf is required to build 
librsvg from stratch, which is considerably hard (it has even more 
indirect dependencies). However eventually I will sort it out (maybe 
after the whole improvement is completed).



Good question, I don't know.  Revising FreeType's build system is
another GSoC project:-)


I saw that project. It will be optimal if he is willing to help us out. 
Unfortunately both Visual Studio and CLion don't play very well with 
MesonBuild. I'm used to use CMake to develop Qt projects in VS, but I'm 
fully open to other options or crafting some new solutions :).



The same – and a lack of stamina.  Improvements are most welcomed.


Definitely, it will be improved if the application is successful.


(IME problem) Interesting.  Alexei?


Maybe I can test it out since I have an environment with multiple IME 
installed (by Microsoft and by 3rd parties).



Do you have suggestions how to improve that (arrow key problem)?


I will give it a try before the application, since I've worked on 
another project about their console attachment issue recently (see 
https://github.com/restic/restic/issues/3681 
https://github.com/restic/restic/issues/3692 and 
https://github.com/restic/restic/pull/3696, and my username is cqjjjzr).



Ideally yes, allowing `ftinspect` being executed on the command line
as a batch program.  Alas, such an approach doesn't work on Windows
since on that platform you can't execute a GUI program on the command
line.


Not quite, factually `ftinspect` is current executable on the command 
line on Windows (just like on Linux). The commandline arguments are 
working as well, so it shouldn't be a problem here. My consideration is 
the added complexity.



Not all demo programs make sense for inclusion.  `ftbench` and
`ftdiff`, however, are useful.


I see, I'll check these two tools out and include them in my proposal.


No, those skills are not prerequisites.
Not at all:-)   It's great that you are interested in helping us.


It's extremely exciting to hear it :D

Thanks and cheers,
Charlie Jiang

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Werner LEMBERG]

Hello Charlie,


> I'm interested in contributing to the project "*Improve FreeType
> demo programs*".

Very nice, and welcome!

> 1. My main workspace is running Windows 10 and Visual Studio 2019.
>Therefore the binaries are built on that, using mesonbuild.
>However, I'm facing great difficulty building one certain
>dependency *librsvg* on Windows + MSVC.  It has several more
>dependencies.  Although I managed to get most from conan build,
>*Gdk-Pixbuf* is still failing due to a link error in glib (maybe
>glib recipe on conan is also problematic, more testing needed).
>Therefore, on Windows, I manually edited the build.meson of
>freetype-demos, dropping the librsvg dependency and removing the
>|HAVE_LIBRSVG| switch. I wonder about the consequence of doing
>this.

Eventually, the problem with 'librsvg' on Windows should be fixed.
I'm not a Windows user so I can't help (maybe Alexei can).  However, a
quick search in the internet gives me

  https://gitlab.gnome.org/GNOME/librsvg/-/tree/main/win32

Does this help?  Otherwise, compiling the demo programs without
'librsvg' is fully sufficient for improving the demo programs.

>I noticed two build systems are maintained for ftinspect (meson
>and qmake) - is it desired?

Good question, I don't know.  Revising FreeType's build system is
another GSoC project :-)

>The grid size is definite, so the character size may exceed the grid
>size.

This is due to my limited knowledge of Qt programming.  The grid
should be indefinite.

>Some convenience operations are missing in the ftinspect program
>(no drag-drop file open, no mouse wheel zoom etc.).

The same – and a lack of stamina.  Improvements are most welcomed.

> 4. I've played around with ftgrid and ftview, but not all features
>of them.  They directly crash when I press "?" if an IME is
>enabled (e.g. MS Pinyin Input Method).

Interesting.  Alexei?

>Some keys are not working on Windows (notably arrow keys, maybe
>related to console-attachment problems) The keyboard-based
>control is not so straightforward (at least for Windows users),
>and moving towards a fully Qt-based GUI could certainly relieve
>this.

Do you have suggestions how to improve that?

>However, I noticed some automation functionalities are present
>(-k option, and p stroke).  Should I consider them in ftinspect
>project?

Ideally yes, allowing `ftinspect` being executed on the command line
as a batch program.  Alas, such an approach doesn't work on Windows
since on that platform you can't execute a GUI program on the command
line.

> 5. There're other tools besides ftgrid and ftview (ftbench, ftchkwd,
>ftdiff ...). Should I include all of them in ftinspect as well?

Not all demo programs make sense for inclusion.  `ftbench` and
`ftdiff`, however, are useful.

> 6. I'm not familiar with text rendering and font processing,
>therefore I'm refering to FreeType documentations and other
>online materials.  Are those skills considered as prerequisites
>before I submit my proposal?

No, those skills are not prerequisites.

> 7. The proposal submitting has already begun. Am I too late to begin a
>proposal?

Not at all :-)  It's great that you are interested in helping us.


   Werner

Re: GSoC

[Sarthak Bhardwaj]

>
>
> Hello Werner,

>
> As you might have noticed, Anurag is recently working on some issues
>
that exactly belong to your GSoC project.
>
>   https://gitlab.freedesktop.org/freetype/freetype/-/issues/1054
>   https://gitlab.freedesktop.org/freetype/freetype-demos/-/issues/1
>   https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/35
>
> Please chime in!
>
Yes I have seen his work and  we have also discussed the various parts and
aims for this project that need to be accomplished. I have also done some
work on that but was little confused that whether it is allowed or kind of
legal to send MR before the coding period or not. But I think now there is
no such issue with that. We will try our best to have this project's
discussion in a constructive way, will for the best:)

Thanks
Sarthak Bhardwaj

>
>
>
>

Re: GSoC

[Werner LEMBERG]

Hello Sarthak,


> I have recently received my GSoC selection mail. I would like to
> thank my mentor @Werner LEMBERG  and other Freetype
> community members for their constant support and guidance.
> 
> It will be my privilege to work with such a wonderful organization,
> will try my best for this project's completion on time.

Good to hear, and thanks for being with us.  I hope you have a nice
time while working on FreeType!

As you might have noticed, Anurag is recently working on some issues
that exactly belong to your GSoC project.

  https://gitlab.freedesktop.org/freetype/freetype/-/issues/1054
  https://gitlab.freedesktop.org/freetype/freetype-demos/-/issues/1
  https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/35

Please chime in!


Werner

Re: GSoC

[sarthak bhardwaj]

Alright! thanks for clearing that up :)

On Sat, Apr 3, 2021 at 5:05 PM Alexei Podtelezhnikov 
wrote:

> Dear applicants,
>
> GSoC is a competition.
>
> We'll select the best and the most realistic proposal for 6 weeks of
> work. Do not try to boil the ocean or start from scratch! I guess you
> are allowed to coordinate right now to make sure that your proposals
> do not overlap, but you do not have to. The rules are straightforward
> and we do not intend to bend them.
>
> Right now you are competing by writing the best proposal you can.
>
> Alexei
>
> On Sat, Apr 3, 2021 at 2:42 AM Werner LEMBERG  wrote:
> >
> >
> > > Do share your remark over this or can I proceed according to what he
> > > have suggested or what, accordingly i will see the things, and the
> > > most ambiguous thing in current is - whether i have to make proposal
> > > for the entire thing, or just for the subproject he suggested me to
> > > do so.?
> >
> > As discussed in a previous e-mail: Prepare a draft proposal of what
> > *you* want to do!  This might be a only a subset of what we have on
> > our GSoC page.  It should be complete in itself, but it doesn't have
> > to cover everything in case you feel that time is not sufficient.
> >
> > Really, guys: Don't worry too much about those things – we simply want
> > to see good and sound proposals!
> >
> >
> > Werner
>
>
>
> --
> Alexei A. Podtelezhnikov, PhD
>

Re: GSoC

[Alexei Podtelezhnikov]

Dear applicants,

GSoC is a competition.

We'll select the best and the most realistic proposal for 6 weeks of
work. Do not try to boil the ocean or start from scratch! I guess you
are allowed to coordinate right now to make sure that your proposals
do not overlap, but you do not have to. The rules are straightforward
and we do not intend to bend them.

Right now you are competing by writing the best proposal you can.

Alexei

On Sat, Apr 3, 2021 at 2:42 AM Werner LEMBERG  wrote:
>
>
> > Do share your remark over this or can I proceed according to what he
> > have suggested or what, accordingly i will see the things, and the
> > most ambiguous thing in current is - whether i have to make proposal
> > for the entire thing, or just for the subproject he suggested me to
> > do so.?
>
> As discussed in a previous e-mail: Prepare a draft proposal of what
> *you* want to do!  This might be a only a subset of what we have on
> our GSoC page.  It should be complete in itself, but it doesn't have
> to cover everything in case you feel that time is not sufficient.
>
> Really, guys: Don't worry too much about those things – we simply want
> to see good and sound proposals!
>
>
> Werner



-- 
Alexei A. Podtelezhnikov, PhD

Re: GSoC

[Werner LEMBERG]

> Do share your remark over this or can I proceed according to what he
> have suggested or what, accordingly i will see the things, and the
> most ambiguous thing in current is - whether i have to make proposal
> for the entire thing, or just for the subproject he suggested me to
> do so.?

As discussed in a previous e-mail: Prepare a draft proposal of what
*you* want to do!  This might be a only a subset of what we have on
our GSoC page.  It should be complete in itself, but it doesn't have
to cover everything in case you feel that time is not sufficient.

Really, guys: Don't worry too much about those things – we simply want
to see good and sound proposals!


Werner

Re: GSoC

[sarthak bhardwaj]

Hello mentors,

Do share your remark over this or can I proceed according to what he have
suggested or what, accordingly i will see the things,
and the most ambiguous thing in current is -  whether i have to make
proposal for the entire thing, or just for the subproject he suggested me
to do so.?



>
>
>
>
> On Fri, Apr 2, 2021, 16:47 Werner LEMBERG  wrote:
>
>> >> [...]  Thanks to the similar GSoC project last year, there should
>> >> only be incremental improvements necessary and not the need to
>> >> start from scratch.  As far as I can see, the migration of the CI
>> >> to the gitlab instance at freedesktop.org is 100 to 200 lines of
>> >> code, improving the UI is basically a few hundred lines of CSS.
>> >> This can be done over a weekend.
>>
> agreed

> >
>> > Adding a frontend framework or using bootstrap will definitely take
>> > some more time
>>
> ya, it will but will try to make it as fast as I can, as I have a little
bit of experience, let me clear one thing it's not a dynamic frontend
framework like react.js or vue.js it's quite simple and is static FEF.

>
>> Of course.  Multiple solutions are possible!
>>
>> >> Basically I don't mind if there are two students who want to split
>> >> a suggested project into two subprojects.  Note, however, that GSoC
>> >> doesn't allow real collaboration: The students must write separate
>> >> proposals that must *not* refer to each other, must code by
>> >> themselves, etc., etc.  It is a non-trivial task to cleanly define
>> >> such non-interfering subprojects.
>
> yup

>
>
> >
>> > If i am not getting it wrong you mean to say that we should make
>> > different different proposals mentioning separate jobs but related
>> > to the same framework improvement, like we have to divide the tasks
>> > in such primary level and will give it to our proposal, that means
>> > that this project can be divided and we have to mention only those
>> > things in our proposal that is earlier assigned to us to do under
>> > this project, half-half.
>>
>> Yes.  However, I don't say you *should* do this.  What I say is that
>> two students *might* share a project in a 'friendly' way as two
>> completely separate subprojects, with no official collaboration
>> between them.
>>
>
>
> Ok I got your point, so as per the thing we should write the proposal for
> some separate sub-project from this whole project for the betterment of
> this framework, as i don't know about his opinion so i don't want to him
> edit or omit the thing he wanted to do earlier if he will be ok with my
> idea that the niche of migration of CI tool , improving UI and betterment
> of comparison tool and other testing parts will be all his area of work,
>
> while as Alexei suggested working on image generation and then improvement
> of the documetation and adding test case collection and other things which
> are to be needed should be mine.
>
> If he is  ok with that we can do this type of thing it will be like doing
> different different subproject under same projects name , and no
> collaboration to be done like this as you have mentioned earlier.
> Is this alright , or should we have to write proposal for the whole
> project covering each and every aspect individually.
>
> Ps i have not confirmed the thing from his side till now but i think i
> would be good for both of us, i am also expecting his opinion on the list.
>
See I have no issue with it, either way, I just want to work, whether it
will be on a full project or any subproject from this project itself, I
agree that the engagement (so far seen) in other projects are likely to be
less and it can be an option.
and if this is the case what you want me to do to separate our working
domains will totally be decided after the mentor's remark over this,
whatever they will say I am ok with that thing.
Well commenting about the motive of GSoC, it's more about getting students
engagement towards the OSS so that the number of contributors can be
increased, and can get some experience in OS development on a good level.

>
Sarthak Bhardwaj

Re: GSoC

[Werner LEMBERG]

> If he is ok with that we can do this type of thing it will be like
> doing different different subproject under same projects name, and
> no collaboration to be done like this as you have mentioned earlier.

I think the best solution is that you don't use the term 'subproject'
at all.  Instead, simply suggest *a project* that you would like to do
(and introduce it on the mailing list), and that probably covers only
parts of what we suggest on our GSoC page.  In the end, it is your
responsibility of what you propose.

> Is this alright, or should we have to write proposal for the whole
> project covering each and every aspect individually.

As mentioned before, every student has to write a complete proposal
that must not refer another one.  And with 'complete' I mean it must
be stand-alone, following the GSoC guidelines.


Werner

Re: GSoC

[Aman Kapoor]

On Fri, Apr 2, 2021, 16:47 Werner LEMBERG  wrote:

> >> [...]  Thanks to the similar GSoC project last year, there should
> >> only be incremental improvements necessary and not the need to
> >> start from scratch.  As far as I can see, the migration of the CI
> >> to the gitlab instance at freedesktop.org is 100 to 200 lines of
> >> code, improving the UI is basically a few hundred lines of CSS.
> >> This can be done over a weekend.
> >
> > Adding a frontend framework or using bootstrap will definitely take
> > some more time
>
> Of course.  Multiple solutions are possible!
>
> >> Basically I don't mind if there are two students who want to split
> >> a suggested project into two subprojects.  Note, however, that GSoC
> >> doesn't allow real collaboration: The students must write separate
> >> proposals that must *not* refer to each other, must code by
> >> themselves, etc., etc.  It is a non-trivial task to cleanly define
> >> such non-interfering subprojects.
> >
> > If i am not getting it wrong you mean to say that we should make
> > different different proposals mentioning separate jobs but related
> > to the same framework improvement, like we have to divide the tasks
> > in such primary level and will give it to our proposal, that means
> > that this project can be divided and we have to mention only those
> > things in our proposal that is earlier assigned to us to do under
> > this project, half-half.
>
> Yes.  However, I don't say you *should* do this.  What I say is that
> two students *might* share a project in a 'friendly' way as two
> completely separate subprojects, with no official collaboration
> between them.
>


Ok I got your point, so as per the thing we should write the proposal for
some separate sub-project from this whole project for the betterment of
this framework, as i don't know about his opinion so i don't want to him
edit or omit the thing he wanted to do earlier if he will be ok with my
idea that the niche of migration of CI tool , improving UI and betterment
of comparison tool and other testing parts will be all his area of work,

while as Alexei suggested working on image generation and then improvement
of the documetation and adding test case collection and other things which
are to be needed should be mine.

If he is  ok with that we can do this type of thing it will be like doing
different different subproject under same projects name , and no
collaboration to be done like this as you have mentioned earlier.
Is this alright , or should we have to write proposal for the whole project
covering each and every aspect individually.

Ps i have not confirmed the thing from his side till now but i think i
would be good for both of us, i am also expecting his opinion on the list.

Regards
Aman kapoor

>

Re: GSoC

[Werner LEMBERG]

>> [...]  Thanks to the similar GSoC project last year, there should
>> only be incremental improvements necessary and not the need to
>> start from scratch.  As far as I can see, the migration of the CI
>> to the gitlab instance at freedesktop.org is 100 to 200 lines of
>> code, improving the UI is basically a few hundred lines of CSS.
>> This can be done over a weekend.
>
> Adding a frontend framework or using bootstrap will definitely take
> some more time

Of course.  Multiple solutions are possible!

>> Basically I don't mind if there are two students who want to split
>> a suggested project into two subprojects.  Note, however, that GSoC
>> doesn't allow real collaboration: The students must write separate
>> proposals that must *not* refer to each other, must code by
>> themselves, etc., etc.  It is a non-trivial task to cleanly define
>> such non-interfering subprojects.
> 
> If i am not getting it wrong you mean to say that we should make
> different different proposals mentioning separate jobs but related
> to the same framework improvement, like we have to divide the tasks
> in such primary level and will give it to our proposal, that means
> that this project can be divided and we have to mention only those
> things in our proposal that is earlier assigned to us to do under
> this project, half-half.

Yes.  However, I don't say you *should* do this.  What I say is that
two students *might* share a project in a 'friendly' way as two
completely separate subprojects, with no official collaboration
between them.

> As i can see GSoC is not about competitive spirit it's about
> collaborative spirit so it might be possible that we can do it
> better somehow in a team sense.  and i have seen many orgs going the
> same and it is suggestion by me in my humble opinion, Am i taking
> your point right?  So that i can make him aware of that...

GSoC is about collaboration, yes – between the student and the members
of the organization under the supervision of one or more mentors.
However, GSoC is competitive between students, and *no* collaboration
between GSoC students is officially wanted.


Werner

Re: GSoC

[Aman Kapoor]

Thanks for the clarification.

On Fri, Apr 2, 2021, 15:35 Werner LEMBERG  wrote:

>
>
> Hello Aman,
>
>
> > I have read archive on orgs. Mailing list.  I have some doubts, as
> > this year's GSoC time is reduced to half, which implies that project
> > should be smaller, and what sarthak have stated in his earlier mail
> > (four or five points), is quite tough to be completed in such a
> > short span of time, that is migrating CI, improving UI and
> > comparison sol. apart from that if one will approach towards what
> > one of the mentors have suggested i.e image generation it will be
> > quite hectic to manage in only 10 weeks and also to adjust in your
> > proposal's timeline.
>
> I assume that you are talking about the project
>
>   Develop a test framework for checking FreeType's rendering output
>
> right?  If this is the case, I disagree with your conclusions.  Thanks
> to the similar GSoC project last year, there should only be
> incremental improvements necessary and not the need to start from
> scratch.  As far as I can see, the migration of the CI to the gitlab
> instance at freedesktop.org is 100 to 200 lines of code, improving the
> UI is basically a few hundred lines of CSS.  This can be done over a
> weekend.
>
- Adding a frontend framework or using bootstrap will definitely take some
more time and i can't say about migration ci tool, its totally depends on
the student though, thanks for the clarification.

>

>
>
> Note also that it is up to the student to write a proposal that fits
> his or her capabilities, possibly selecting only a subset of the
> project as described on our GSoC page.  It's part of GSoC that
> students estimate the necessary time for something – as in real life
> projects, if you are going to work for a company, say.
>
> > Or is there any probability that for a single project there can be
> > more than one students in GSoC(many orgs do so).  I think this can
> > create some good condition to work on, as for rest of the projects
> > stated in the list, i haven't seen too many students approaching so
> > far.  That will be beneficial for the smooth process.
>
> Basically I don't mind if there are two students who want to split a
> suggested project into two subprojects.  Note, however, that GSoC
> doesn't allow real collaboration: The students must write separate
> proposals that must *not* refer to each other, must code by
> themselves, etc., etc.  It is a non-trivial task to cleanly define
> such non-interfering subprojects.
>

If i am not getting it wrong you mean to say that we should make different
different proposals mentioning separate jobs but related to the same
framework improvement, like we have to divide the tasks in such primary
level and will give it to our proposal, that means that this project can be
divided and we have to mention only those things in our proposal that is
earlier assigned to us to do under this project, half-half.

As i can see GSoC is not about competitive spirit it's about collaborative
spirit so it might be possible that we can do it better somehow in a team
sense.and i have seen many orgs going the same and it is suggestion by me
in my humble opinion, Am i taking your point right?
So that i can make him aware of that...


> > P.S- I have not seen his proposal yet but i am assuming he have
> > mentioned it all that he have stated in his mails for freetype.
> >
> > And i will also be sharing my proposal draft very soon.
>
> Thanks!
>
>
> Werner
>

Re: GSoC

[Werner LEMBERG]

Hello Aman,


> I have read archive on orgs. Mailing list.  I have some doubts, as
> this year's GSoC time is reduced to half, which implies that project
> should be smaller, and what sarthak have stated in his earlier mail
> (four or five points), is quite tough to be completed in such a
> short span of time, that is migrating CI, improving UI and
> comparison sol. apart from that if one will approach towards what
> one of the mentors have suggested i.e image generation it will be
> quite hectic to manage in only 10 weeks and also to adjust in your
> proposal's timeline.

I assume that you are talking about the project

  Develop a test framework for checking FreeType's rendering output

right?  If this is the case, I disagree with your conclusions.  Thanks
to the similar GSoC project last year, there should only be
incremental improvements necessary and not the need to start from
scratch.  As far as I can see, the migration of the CI to the gitlab
instance at freedesktop.org is 100 to 200 lines of code, improving the
UI is basically a few hundred lines of CSS.  This can be done over a
weekend.

Note also that it is up to the student to write a proposal that fits
his or her capabilities, possibly selecting only a subset of the
project as described on our GSoC page.  It's part of GSoC that
students estimate the necessary time for something – as in real life
projects, if you are going to work for a company, say.

> Or is there any probability that for a single project there can be
> more than one students in GSoC(many orgs do so).  I think this can
> create some good condition to work on, as for rest of the projects
> stated in the list, i haven't seen too many students approaching so
> far.  That will be beneficial for the smooth process.

Basically I don't mind if there are two students who want to split a
suggested project into two subprojects.  Note, however, that GSoC
doesn't allow real collaboration: The students must write separate
proposals that must *not* refer to each other, must code by
themselves, etc., etc.  It is a non-trivial task to cleanly define
such non-interfering subprojects.

> P.S- I have not seen his proposal yet but i am assuming he have
> mentioned it all that he have stated in his mails for freetype.
> 
> And i will also be sharing my proposal draft very soon.

Thanks!


Werner

Re: GSOC Project

[Werner LEMBERG]

> [...] for getting well in work with freetype i need to study whole
> documentation of freetype or i just need to have the intro and build
> it to the system,

Of course it's not necessary to read everything, but you should get a
feeling for the library, this is, actively play around with the code,
possibly by writing some small test programs as the beginning.

> In shorts i am asking you to suggest that what are the topics in
> which i should be acquainted so that i will not find any hurdle.

Hard to say.  Look, a GSoC project isn't something you get assigned
to.  It's rather the opposite: You have some interests, and you assign
yourself to stuff that is related to your interests, willing to deeply
dive into the topic.  We are not your bosses who tell you what to do.
The incentive must be yours, and yours only.  This includes to find
out what to read and learn.


Werner

Re: GSOC Project

[Aman Kapoor]

Ok git it thanks werner and one more thing that i want to ask is for
getting well in work with freetype i need to study whole documentation of
freetype or i just need to have the intro and build it to the system,
Inshorts i am asking you to suggest that what are the topics in which i
should be acquaint so that i will not find any hurdle.

Thanks
 Aman

On Thu, Mar 18, 2021, 12:02 Werner LEMBERG  wrote:

>
> Hello Aman,
>
>
> > I am interested in the project -_"Develop a test framework for
> > checking Freetype's rendering output"
>
> Great!
>
> > 1. What signifies the meaning of word "font corpora" as i haven't
> > found anything about by googling it.
>
> A good and valid question.
>
> 'Corpora' is the plural form of the Latin word 'corpus'.  A 'font
> corpus' is a set of fonts that kind-of belong together, or have been
> collected for a common purpose.  For example, each time the FreeType
> fuzzer finds a problem, the offending fuzzed font gets added to such a
> corpus.
>
> For the problem of checking the rendering output, collecting fonts for
> a similar corpus is necessary.  Ideally, the elements of this corpus
> should be tiny fonts of various font formats that either
>
> (1) increase the code coverage of the FreeType (mainly to check error
> handling)
>
> or
>
> (2) test all aspects of the rendering pipeline, covering as much
> features as possible.
>
> For the GSoC task at hand, (1) can be ignored more or less, since it
> doesn't contribute to visual differences.
>
> A serious problem is that many important fonts are commercial fonts,
> which can't be directly added to a freely available corpus.  Most
> fonts, however, allow subsetting, and collecting subsetted fonts is
> similar to collecting PDF files that contain them and thus legally
> allowed.[*]
>
> Let's assume that glyph 'foo' of font 'bar' causes a rendering
> problem.  A logical step would be to create a subsetted font of 'bar'
> that contains just this single 'foo' glyph (more or less).
>
> > 2. Where can i find instructions to build free type
>
> Well, as with almost all source code package you should start with the
> `README` file :-)
>
>   https://gitlab.freedesktop.org/freetype/freetype
>
>
> Werner
>
>
> [*] At least this is what I think.  It should be otherwise possible to
> construct a minimum PDF file around a subsetted font.
>

Re: GSOC Project

[Werner LEMBERG]

Hello Aman,


> I am interested in the project -_"Develop a test framework for
> checking Freetype's rendering output"

Great!

> 1. What signifies the meaning of word "font corpora" as i haven't
> found anything about by googling it.

A good and valid question.

'Corpora' is the plural form of the Latin word 'corpus'.  A 'font
corpus' is a set of fonts that kind-of belong together, or have been
collected for a common purpose.  For example, each time the FreeType
fuzzer finds a problem, the offending fuzzed font gets added to such a
corpus.

For the problem of checking the rendering output, collecting fonts for
a similar corpus is necessary.  Ideally, the elements of this corpus
should be tiny fonts of various font formats that either

(1) increase the code coverage of the FreeType (mainly to check error
handling)

or

(2) test all aspects of the rendering pipeline, covering as much
features as possible.

For the GSoC task at hand, (1) can be ignored more or less, since it
doesn't contribute to visual differences.

A serious problem is that many important fonts are commercial fonts,
which can't be directly added to a freely available corpus.  Most
fonts, however, allow subsetting, and collecting subsetted fonts is
similar to collecting PDF files that contain them and thus legally
allowed.[*]

Let's assume that glyph 'foo' of font 'bar' causes a rendering
problem.  A logical step would be to create a subsetted font of 'bar'
that contains just this single 'foo' glyph (more or less).

> 2. Where can i find instructions to build free type

Well, as with almost all source code package you should start with the
`README` file :-)

  https://gitlab.freedesktop.org/freetype/freetype


Werner


[*] At least this is what I think.  It should be otherwise possible to
construct a minimum PDF file around a subsetted font.

Re: GSoC

[Werner LEMBERG]

Hello Giorgos!


> I would like to contribute to one of your GSoc 2021 projects and
> more precisely in the "Improve FreeType demo programs" project.  The
> last few days (from the organizations announcing) I look into the
> git-repo code and I am quite excited.

Great!

> I would like to ask you if there is something that I could do from
> now, to warm up and get more familiar with the project.  Can you
> point me to a more specific direction?

Please tell us first what you tried already, and what interests you
most.  What you can always do, for example, is to submit merge
requests that add comments to the source code, making it easier to
understand – this might help both you and other future developers.

The same is true for the documentation.  It is always valuable if
people get a fresh, new look because they see (or miss) things that we
no longer notice.


Werner

Re: GSOC Build tests

[Greg Williamson]

Ok I've wrapped the readme lines as requested

On Sun, Aug 30, 2020 at 4:02 PM Werner LEMBERG  wrote:
>
>
> > Ok I believe I was able to commit to savannah but the message is a
> > bit cryptic:
>
> Everything's fine, thanks.
>
> > I also added a readme as requested in CI/readme.md.
>
> Thanks.  Please reformat the file to make the lines not longer than 78
> characters.
>
> > Can anyone confirm this worked and tell me how I can link to it in
> > my final evaluation?
>
> Use this
>
>   https://git.savannah.gnu.org/cgit/freetype/freetype2.git/?h=GSoC-2020-greg
>
> or something similar offered on that page (whatever fits you best).
>
> > I was also able to fix a few msys build errors but I still cannot
> > build demos in msys due it trying to include termios.h which is not
> > available. For now, I've temporarily disabled building demos for that
> > platform.
>
> OK.
>
>
> Werner

Re: GSOC Build tests

[Werner LEMBERG]

> Ok I believe I was able to commit to savannah but the message is a
> bit cryptic:

Everything's fine, thanks.

> I also added a readme as requested in CI/readme.md.

Thanks.  Please reformat the file to make the lines not longer than 78
characters.

> Can anyone confirm this worked and tell me how I can link to it in
> my final evaluation?

Use this

  https://git.savannah.gnu.org/cgit/freetype/freetype2.git/?h=GSoC-2020-greg

or something similar offered on that page (whatever fits you best).

> I was also able to fix a few msys build errors but I still cannot
> build demos in msys due it trying to include termios.h which is not
> available. For now, I've temporarily disabled building demos for that
> platform.

OK.


Werner

Re: GSOC Build tests

[Greg Williamson]

Ok I believe I was able to commit to savannah but the message is a bit cryptic:

[greg@greg-desktop savannah-freetype2]$ git push --set-upstream origin
GSoC-2020-greg
Enumerating objects: 23, done.
Counting objects: 100% (23/23), done.
Delta compression using up to 8 threads
Compressing objects: 100% (19/19), done.
Writing objects: 100% (19/19), 21.39 KiB | 10.69 MiB/s, done.
Total 19 (delta 5), reused 0 (delta 0), pack-reused 0
remote: *** no recipients configured so no email will be sent
remote: *** for 'refs/heads/GSoC-2020-greg' update
None->3f82a109c0f16458b05110beeb2ad443ba0274bd
To git.savannah.nongnu.org:/srv/git/freetype/freetype2.git
 * [new branch]  GSoC-2020-greg -> GSoC-2020-greg
Branch 'GSoC-2020-greg' set up to track remote branch 'GSoC-2020-greg'
from 'origin'.

I also added a readme as requested in CI/readme.md.

Can anyone confirm this worked and tell me how I can link to it in my
final evaluation?

I was also able to fix a few msys build errors but I still cannot
build demos in msys due it trying to include termios.h which is not
available. For now, I've temporarily disabled building demos for that
platform.

On Sat, Aug 29, 2020 at 10:23 AM Werner LEMBERG  wrote:
>
>
> Hello Greg,
>
>
> sorry for the late reply.
>
> > As, discussed with Werner I have:
> > 1) added a simple config file (in CI/ft-tests.config)
> > 2) split the tests into smaller chunks
> > 3) changed the colors of the diff images to green / red
> > 4) added the diff images to the generated comparison page
> > 5) fixed the relative paths in the generated comparison page
>
> This looks good, thanks.  However, I miss a README document that
> explains where to start...
>
> > I have also made an attempt to add a fix for the MinGW builds but it
> > appears your make install script can't handle window paths so we'll
> > need to sed the \ to / or something to fix that build test.
>
> Please show an error log.  Maybe it's easy to fix.
>
> > If you have any issues or questions about my code I will still be
> > checking this email even after GSoC so let me know and I will do my
> > best to fix whatever is wrong.
>
> Great, thanks!
>
> > In the gitlab migration listing I can talk about integrating this
> > before or after you move but I am more familiar with github and can
> > only really answer questions on my azure config file and scripts or
> > integrating it with github.
>
> We would be indeed glad if you could assits with CI stuff since my
> knowledge is essentially zero.
>
> > As for my side of the GSoC evaluation, Where do your students
> > typically link to for the "showcase" of their project?
>
> You should put your code into a branch named 'GSoC-2020-greg' (or
> something similar) of the FreeType repository.
>
> > I was never able to successfully push to your repo
>
> This we have to fix right now.  What exactly is the problem?  Have you
> uploaded an SSH key to Savannah for your account?
>
>   https://savannah.gnu.org/maintenance/SshAccess/
>
> Be careful not to add a final newline character that some editors
> automatically insert.  After this, you should be able to checkout the
> FreeType repositories with
>
>   git clone fund...@git.savannah.nongnu.org:/srv/git/freetype/freetype2.git
>   git clone 
> fund...@git.savannah.nongnu.org:/srv/git/freetype/freetype2-demos.git
>
>
> Werner

Re: GSOC Build tests

[Greg Williamson]

Ok I believe I was able to commit to savannah but the message is a bit cryptic:

[greg@greg-desktop savannah-freetype2]$ git push --set-upstream origin
GSoC-2020-greg
Enumerating objects: 23, done.
Counting objects: 100% (23/23), done.
Delta compression using up to 8 threads
Compressing objects: 100% (19/19), done.
Writing objects: 100% (19/19), 21.39 KiB | 10.69 MiB/s, done.
Total 19 (delta 5), reused 0 (delta 0), pack-reused 0
remote: *** no recipients configured so no email will be sent
remote: *** for 'refs/heads/GSoC-2020-greg' update
None->3f82a109c0f16458b05110beeb2ad443ba0274bd
To git.savannah.nongnu.org:/srv/git/freetype/freetype2.git
 * [new branch]  GSoC-2020-greg -> GSoC-2020-greg
Branch 'GSoC-2020-greg' set up to track remote branch 'GSoC-2020-greg'
from 'origin'.

I also added a readme as requested in CI/readme.md.

Can anyone confirm this worked and tell me how I can link to it in my
final evaluation?

I was also able to fix a few msys build errors but I still cannot
build demos in msys due it trying to include termios.h which is not
available. For now, I've temporarily disabled building demos for that
platform.

On Sat, Aug 29, 2020 at 10:23 AM Werner LEMBERG  wrote:
>
>
> Hello Greg,
>
>
> sorry for the late reply.
>
> > As, discussed with Werner I have:
> > 1) added a simple config file (in CI/ft-tests.config)
> > 2) split the tests into smaller chunks
> > 3) changed the colors of the diff images to green / red
> > 4) added the diff images to the generated comparison page
> > 5) fixed the relative paths in the generated comparison page
>
> This looks good, thanks.  However, I miss a README document that
> explains where to start...
>
> > I have also made an attempt to add a fix for the MinGW builds but it
> > appears your make install script can't handle window paths so we'll
> > need to sed the \ to / or something to fix that build test.
>
> Please show an error log.  Maybe it's easy to fix.
>
> > If you have any issues or questions about my code I will still be
> > checking this email even after GSoC so let me know and I will do my
> > best to fix whatever is wrong.
>
> Great, thanks!
>
> > In the gitlab migration listing I can talk about integrating this
> > before or after you move but I am more familiar with github and can
> > only really answer questions on my azure config file and scripts or
> > integrating it with github.
>
> We would be indeed glad if you could assits with CI stuff since my
> knowledge is essentially zero.
>
> > As for my side of the GSoC evaluation, Where do your students
> > typically link to for the "showcase" of their project?
>
> You should put your code into a branch named 'GSoC-2020-greg' (or
> something similar) of the FreeType repository.
>
> > I was never able to successfully push to your repo
>
> This we have to fix right now.  What exactly is the problem?  Have you
> uploaded an SSH key to Savannah for your account?
>
>   https://savannah.gnu.org/maintenance/SshAccess/
>
> Be careful not to add a final newline character that some editors
> automatically insert.  After this, you should be able to checkout the
> FreeType repositories with
>
>   git clone fund...@git.savannah.nongnu.org:/srv/git/freetype/freetype2.git
>   git clone 
> fund...@git.savannah.nongnu.org:/srv/git/freetype/freetype2-demos.git
>
>
> Werner

Re: GSOC Build tests

[Werner LEMBERG]

Hello Greg,


sorry for the late reply.

> As, discussed with Werner I have:
> 1) added a simple config file (in CI/ft-tests.config)
> 2) split the tests into smaller chunks
> 3) changed the colors of the diff images to green / red
> 4) added the diff images to the generated comparison page
> 5) fixed the relative paths in the generated comparison page

This looks good, thanks.  However, I miss a README document that
explains where to start...

> I have also made an attempt to add a fix for the MinGW builds but it
> appears your make install script can't handle window paths so we'll
> need to sed the \ to / or something to fix that build test.

Please show an error log.  Maybe it's easy to fix.

> If you have any issues or questions about my code I will still be
> checking this email even after GSoC so let me know and I will do my
> best to fix whatever is wrong.

Great, thanks!

> In the gitlab migration listing I can talk about integrating this
> before or after you move but I am more familiar with github and can
> only really answer questions on my azure config file and scripts or
> integrating it with github.

We would be indeed glad if you could assits with CI stuff since my
knowledge is essentially zero.

> As for my side of the GSoC evaluation, Where do your students
> typically link to for the "showcase" of their project?

You should put your code into a branch named 'GSoC-2020-greg' (or
something similar) of the FreeType repository.

> I was never able to successfully push to your repo

This we have to fix right now.  What exactly is the problem?  Have you
uploaded an SSH key to Savannah for your account?

  https://savannah.gnu.org/maintenance/SshAccess/

Be careful not to add a final newline character that some editors
automatically insert.  After this, you should be able to checkout the
FreeType repositories with

  git clone fund...@git.savannah.nongnu.org:/srv/git/freetype/freetype2.git
  git clone 
fund...@git.savannah.nongnu.org:/srv/git/freetype/freetype2-demos.git


Werner

Re: GSOC Build tests

[Greg Williamson]

As, discussed with Werner I have:
1) added a simple config file (in CI/ft-tests.config)
2) split the tests into smaller chunks
3) changed the colors of the diff images to green / red
4) added the diff images to the generated comparison page
5) fixed the relative paths in the generated comparison page

I have also made an attempt to add a fix for the MinGW builds but it
appears your make install script can't handle window paths so we'll
need to sed the \ to / or something to fix that build test.

The current patch is here:
https://patch-diff.githubusercontent.com/raw/fundies/freetype2/pull/1.patch
You can see the CI in action here:
https://dev.azure.com/fundies/freetype2/_build/results?buildId=237=logs=05dc4cca-e891-599c-177e-6a5b81dbe26c=05dc4cca-e891-599c-177e-6a5b81dbe26c
You can download an example test run here:
https://dev.azure.com/fundies/9eabb07a-6a4d-4b68-b22e-60f9e02c1927/_apis/build/builds/237/artifacts?artifactName=Archlinux%20Regression%20tests%20Test2=6.0&%24format=zip

If you have any issues or questions about my code I will still be
checking this email even after GSoC so let me know and I will do my
best to fix whatever is wrong.

In the gitlab migration listing I can talk about integrating this
before or after you move but I am more familiar with github and can
only really answer questions on my azure config file and scripts or
integrating it with github.

As for my side of the GSoC evaluation, Where do your students
typically link to for the "showcase" of their project? I was never
able to successfully push to your repo so I just moved on and worked
on my project on github. However, as it's not an official mirror I
don't think it'd be appropriate to link there.

On Thu, Aug 6, 2020 at 1:40 AM Werner LEMBERG  wrote:
>
>
> Hi Greg,
>
>
> sorry for the late response.
>
>
> > [...] if you have no preference I have an easy way to handle configs
> > in mind.  It won't be the prettiest config file you've ever seen but
> > it should minimize the amount of additional code needed.
>
> Just proceed, please!
>
> >> Looking around I've found the difference png – what do you think of
> >> slightly coloring the differences?  And for comparing B/W images, I
> >> remember that I've coloured points only in the reference image as
> >> green and in the new image as red...
> >
> > As for the diff image you saw, I am limited to what imagick can do.
> > You can see an overview of their image diff modes here:
> > http://www.imagemagick.org/Usage/compare/#methods
>
> Ah, ok.
>
> > I can use any of these and even multiple of them but the more images
> > the larger the zip of course. Please have a peek and let me know
> > which modes you think would be most useful to you and I can add them
> > to the diffing page.
>
> Just something with color :-)
>
> > The highlight/lowlight example on the page is what you mean when
> > youre talking about green/red?
>
> Maybe, I'm not sure.  What I did was the following for a comparsion
> between two bitmaps A and B:
>
>   present in Apresent in Bcolor
>   -
>0   0  white
>1   0  green
>0   1  red
>1   1  black
>
> For hovering bitmaps this would be a possibility.  For hovering
> graymaps I guess it doesn't work.
>
> > I am/will be working on what we've discussed above and hope to have a
> > new patch / commit for you soon.
>
> Great.  Please send an e-mail to the list if you have something to
> show.
>
>
> Werner

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

[Werner LEMBERG]

>> Thanks, too.  What do you think about integrating this into (at
>> least) `ftview`?
> 
> Yes, it can be integrated into the existing demo programs, however I
> think it should have a separate demo program because of the way SDF
> is rendered, it has a raw and reconstruction view as well as various
> properties and bilinear filtering.  Because of that I think
> integrating it completely into the existing programs will clutter
> the programs.

OK, no problem to add another test program :-) Please make it behave
similar to the other ones as much as posible for the sake of
orthogonality.

> On the other hand It makes sense to integrate them into the existing
> programs, so that we can compare them with other renderers and see
> how it looks.  It will require significant changes to the graphics
> subsytem (adding bilinear filtering, render 16 bpp, the
> reconstruction mode etc.).  So, perhaps I should do it after GSoC?

This would be great, of course!  However, if you want to invest some
time in this area please have a look at the `ftinspect` program, which
is intended as a modern replacement and synthesis of all demo
programs.  [There are also some improvements in the
'veeki-gsoc-experimental' branch, which unfortunately don't fly, so to
say.  Maybe some of it is useful.]


Werner

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

[Anuj Verma]

 >> Werner, Are you still interested in adding API to remove overlaps?
>
> Yes, I am.

Alright, I will start reading more about it after GSoC.

>> I have updated the demo to include the new algorithm to handle
>> overlaps.  [...]
>
> Thanks, too.  What do you think about integrating this into (at least)
> `ftview`?

Yes, it can be integrated into the existing demo programs, however I
think it should have a separate demo program because of the way
SDF is rendered, it has a raw and reconstruction view as well as
various properties and bilinear filtering. Because of that I think
integrating it completely into the existing programs will clutter the
programs.
On the other hand It makes sense to integrate them into the
existing programs, so that we can compare them with other
renderers and see how it looks. It will require significant changes
to the graphics subsytem (adding bilinear filtering, render 16 bpp,
the reconstruction mode etc.). So, perhaps I should do it after GSoC?

Anuj

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

[Werner LEMBERG]

> Werner, Are you still interested in adding API to remove overlaps?

Yes, I am.

> I watched the skia code and the video on how it's done in skia.  I
> think it's doable, the only tricky part that I think is to find the
> intersecting point of contours, because they use a 4th degree
> polynomial to find the intersections.  If you're still interested in
> adding the API, I can start reading more about it after GSoC and
> then add it.

This would be really great.  Thanks for the offer!

> I have updated the demo to include the new algorithm to handle
> overlaps.  [...]

Thanks, too.  What do you think about integrating this into (at least)
`ftview`?

> And then I will write a brief description of how both `sdf' and
> `bsdf' renderers work in the source files.  And finally I will
> create a new branch and add the code there.  If there is anything
> else please do let me know.

Your plan sounds just fine :-)


Werner

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

[Anuj Verma]

Hello Alexei, Werner,

>> I meant it all along but perhaps it is hard to do it on the fly. Ther
>> rules seem to be as follows:
>>
>> 1) Both outside (both positive), choose a smaller value
>> 2) Both inside (both negative), choose a smaller value as in (-5 < -4)
>> not by absolute value
>> 3) one inside one outside, choose a smaller value as in (-3 < 2) not
>> by absolute value
>>
>> I.e. always choose a smaller value combining two contours so it seems
>
> Along with this we probably also need to find the resultant vector in case
> two distances are non infinite at a same point (i.e. the distance values
are
> less than spread), that we can find the distance to the corner even tho
> there is no actual corner in some glyphs.

I've added the overlapping support according to your algorithm, however I
have
modified the rule as follows:

-> Generate SDF for each contour in a separate bitmap.
-> for combining all the SDF to one use the below rule:
  -> for each pixel/grid point:
   c = for all clockwise contours find the largest signed value.
ac = for all counter-clockwise contours find the smallest
signed value.
   final_value = smallest signed value of `c' and `ac'.

It works well for all of the glyphs that I checked apart from glyphs with
self
intersecting contours, because they can't be separated into different
bitmaps. To
handle self intersecting contours I think there is only one way and that is
to remove
the overlaps.

[
Werner,
  Are you still interested in adding API to remove overlaps? I watched the
skia code
  and the video on how it's done in skia. I think it's doable, the only
tricky part that I
  think is to find the intersecting point of contours, because they use a
4th degree
  polynomial to find the intersections.
  If you're still interested in adding the API, I can start reading more
about it after GSoC
  and then add it.
]

I have updated the demo to include the new algorithm to handle overlaps. I
have also
disabled all the optimization modes except the subdivision optimization (it
will be the
default one from now on until I find something even faster). Here is the
link:
https://github.com/preversewharf45/ft2sdf-demo, for help screen press '?'
or F1. There is
a `CascadiaCode.ttf' font which is full of overlaps, so that you can check
how the new
algorithm performs.

And now that GSoC is almost over, I will fix the compiler warnings first.
And then I will
write a brief description of how both `sdf' and `bsdf' renderers work in
the source files.
And finally I will create a new branch and add the code there. If there is
anything else
please do let me know.

Thanks,
Anuj

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

[Anuj Verma]

 > I meant it all along but perhaps it is hard to do it on the fly. Ther
> rules seem to be as follows:
>
> 1) Both outside (both positive), choose a smaller value
> 2) Both inside (both negative), choose a smaller value as in (-5 < -4)
> not by absolute value
> 3) one inside one outside, choose a smaller value as in (-3 < 2) not
> by absolute value
>
> I.e. always choose a smaller value combining two contours so it seems

Along with this we probably also need to find the resultant vector in case
two distances are non infinite at a same point (i.e. the distance values are
less than spread), that we can find the distance to the corner even tho
there is no actual corner in some glyphs.

Also, my progress has been slow lately because my classes have started
and there is the campus placement thing going on. I haven't yet started
doing the overlapping support, I will try to add it by next next week and
see if it works.

Thanks,
Anuj

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

[Alexei Podtelezhnikov]

> I.e. always choose a smaller value combining two contours so it seems

This might be oversimplified, but it is clear that the sign is
supposed to agree with the winding number and the priority of
distances should be defined by the fill rule.

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

[Alexei Podtelezhnikov]

On Fri, Aug 7, 2020 at 10:58 AM Anuj Verma  wrote:
>
> > Yeah. We should basically think of overlaying or combining two
> > distance fields, generated independently one for each contour.
> > Has this been discussed in the literature?
>
> No, it has not been. That sounds interesting, thanks for the idea.
> I will think about it tomorrow, perhaps it might solve the issue. My
> only concern would be the additional memory usage, because some
> glyphs have many contours. But yeah we can turn it ON only for
> overlapping contours.

I meant it all along but perhaps it is hard to do it on the fly. Ther
rules seem to be as follows:

1) Both outside (both positive), choose a smaller value
2) Both inside (both negative), choose a smaller value as in (-5 < -4)
not by absolute value
3) one inside one outside, choose a smaller value as in (-3 < 2) not
by absolute value

I.e. always choose a smaller value combining two contours so it seems

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

[Anuj Verma]

 > Yeah. We should basically think of overlaying or combining two
> distance fields, generated independently one for each contour.
> Has this been discussed in the literature?

No, it has not been. That sounds interesting, thanks for the idea.
I will think about it tomorrow, perhaps it might solve the issue. My
only concern would be the additional memory usage, because some
glyphs have many contours. But yeah we can turn it ON only for
overlapping contours.

Thanks for the idea,
Anuj

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

[Alexei Podtelezhnikov]

On Fri, Aug 7, 2020 at 12:54 AM Anuj Verma  wrote:
>
> Hello Alexei,
>
> > Can you describe discontinuities with the same sign if I overlook them?
>
> So, I found there are two types of discontinuities due to overlapping 
> contours:
>
> A) Discontinuity in sign. (i.e. there is a sudden jump from negative to 
> positive)
> B) Discontinuity in distances. (i.e. the points that should be at 
> infinity/spread have smaller distances)

Yeah. We should basically think of overlaying or combining two
distance fields, generated independently one for each contour.
Has this been discussed in the literature?

> Also, I looked at a library (msdfgen) which handles overlapping contours 
> without
> removing the overlaps. It works well, but it doesn't work for 
> self-intersecting contours,
> that is why I'm not sure whether it's worth implementing.

Self intersecting contours should never and hopefully will never be
allowed in fonts.

> Finally, I can find and fix signs such that all points inside a shape are 
> positive and
> all points outside are negative. But I don't know how I can fix the incorrect 
> distances
> caused by the overlaps. Here is one final example: 
> https://i.imgur.com/jiaqiBS.png
> In this the point `P' has a positive sign and it points to a line inside the 
> shape, which
> is not correct, instead it should point to the corner. Moreover there is no 
> corner in the
> shape because they are two separate contours, so I think removing the 
> overlaps is
> the best way to handle this.

Here I concede we will never find proper distance unless we define the
intersection point.

Alexei

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

[Anuj Verma]

Hello Alexei,

> Can you describe discontinuities with the same sign if I overlook them?

So, I found there are two types of discontinuities due to overlapping
contours:

A) Discontinuity in sign. (i.e. there is a sudden jump from negative to
positive)
B) Discontinuity in distances. (i.e. the points that should be at
infinity/spread have smaller distances)

Here is an example of a SDF generated from glyph with overlaps:
https://i.imgur.com/3pqHZWd.png
In that image the right side is correct (generated from bitmap), and the
left side has both A and B
types of  discontinuities.

What you are saying about detecting sudden jump from large negative to large
positive can work for discontinuities in sign. I tried that and here is an
example: https://i.imgur.com/unRB23Z.png
(ignore the weird lines in the image, that can be fixed). But even after
fixing the
sign there are pixels inside the outline which have shortest distance to
the curves
inside the outline. (basically the pixels around the overlap points to the
overlapping
curve, which causes discontinuous distances). Moreover they interpolate
smoothly
so there is no way to find the actual distance which will be to some curve
at the border
of the outline instead of inside the outline.

Also, I looked at a library (msdfgen) which handles overlapping contours
without
removing the overlaps. It works well, but it doesn't work for
self-intersecting contours,
that is why I'm not sure whether it's worth implementing.

Finally, I can find and fix signs such that all points inside a shape are
positive and
all points outside are negative. But I don't know how I can fix the
incorrect distances
caused by the overlaps. Here is one final example:
https://i.imgur.com/jiaqiBS.png
In this the point `P' has a positive sign and it points to a line inside
the shape, which
is not correct, instead it should point to the corner. Moreover there is no
corner in the
shape because they are two separate contours, so I think removing the
overlaps is
the best way to handle this.

Thanks,
Anuj

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

[Alexei Podtelezhnikov]

Hi Anuj,

> > If I understand correctly, overlaps cause unexpected discontinuity in
> > SDF, which otherwise should not have any. I doubt that detecting and
> > removing contour overlaps is productive. I would rather deal with the
> > discontinuity directly. Perhaps there is a clever way to ignore
> > smaller distances that unexpectedly have an opposite sign. The
> > distance cannot change by more than the grid size. If it does, ignore
> > the offending value.
>
> Yes, overlaps cause discontinuity in both sign and distances. Detecting
> unexpected opposite sign is possible, but the sign may not be opposite.
> In many cases the sign is not flipped (there is no unexpected change
> in sign) and the distances interpolate smoothly, in those cases it becomes
> hard to find the true distances of the point.

I still think that it should be possible to ignore distances that
result in discontinuities. The distance field has to be continuous
from edge to edge, from clamped "infinity" to clamped "infinity", with
continuity defined as not changing by more than a grid size. The signs
are allowed to flip only then crossing line segments (i.e. scanning
the line neighborhood, rather than overriding a previous value). As
you scan a neighborhood for a line and encounter a previously recorded
(not "infinite") value you should override only if it has the same
sign and smaller magnitude.

Can you describe discontinuities with the same sign if I overlook them?

Thank you
Alexei

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

[Werner LEMBERG]

Hello Anuj,


> I have mostly completed the bitmap to SDF renderer (bsdf), there are
> only a few things remaining such as support for all pixel modes
> (currently it only work with FT_PIXEL_MODE_GRAY), and warnings etc.

Excellent, thanks!

> Next, I will be finishing the bsdf renderer and then writing the
> documentation for all the functions (should I write for structs as
> well? i.e. detailed description of all the members).

Yes, please.  The more the merrier :-) To be serious: A few months in
the future even you will start to forget most of the details.  Always
have in mind that people will look at your stuff who have never seen
it before, and who don't have the time to walk through the complete
code to get all the necessary information.

> Also is there any other kind of documentation that I should add?

I don't think so.  Will tell you otherwise :-)

> After that I have not decided what to do.  I have a few things in
> mind (adding floating point support, removing overlaps and a few
> more).  But we can discuss that once I have finished the
> documentation.  (Also, I will keep improving the existing
> algorithms, optimizing and removing any bug that I find along the
> way)

In mid-August I suggest that you start cleaning up your git branch,
this is, you create a new branch and populate it with new commits that
introduce SDF and BSDF in small, incremental, and logical steps.  This
mainly affects the stuff that has to be added to already existing
files.  Code in new files don't have to be handled that way, of
course, if it doesn't make sense.

> I have updated the demo
> (https://github.com/preversewharf45/ft2sdf-demo) and this time I
> have added the help screen ('?' or F1), I have also included a font
> `CascadiaCode.ttf' which is full of overlaps, so that you can
> compare both the renderers.

Great!  Will test soon.


Werner

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

[Anuj Verma]

> Only FT_PIXEL_MODE_MONO is necessary to add. I do not understand how
> LCD or BGRA can be used for SDF; GRAY2 and GRAY4 are defunct.

It might be possible to convert LCD and BGRA to SDF, either using  a single
channel or by converting them to grayscale, but yeah I don't think that
will be
useful. And I will skip GRAY2 and GRAY4.

> If I understand correctly, overlaps cause unexpected discontinuity in
> SDF, which otherwise should not have any. I doubt that detecting and
> removing contour overlaps is productive. I would rather deal with the
> discontinuity directly. Perhaps there is a clever way to ignore
> smaller distances that unexpectedly have an opposite sign. The
> distance cannot change by more than the grid size. If it does, ignore
> the offending value.

Yes, overlaps cause discontinuity in both sign and distances. Detecting
unexpected opposite sign is possible, but the sign may not be opposite.
In many cases the sign is not flipped (there is no unexpected change
in sign) and the distances interpolate smoothly, in those cases it becomes
hard to find the true distances of the point.
There is a way to do it, which is done in the 'msdfgen' library, but it is
not perfect and I don't know whether it will work with subdivision
optimization
or not.
I will try to think of some other way of handling overlaps without actually
removing overlaps, but I think the most robust way to do it would be to
remove the overlaps.

Thanks,
Anuj

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

[Alexei Podtelezhnikov]

Hi Anuj,

> I have mostly completed the bitmap to SDF renderer (bsdf), there
> are only a few things remaining such as support for all pixel
> modes (currently it only work with FT_PIXEL_MODE_GRAY),

Only FT_PIXEL_MODE_MONO is necessary to add. I do not understand how
LCD or BGRA can be used for SDF; GRAY2 and GRAY4 are defunct.

> After that I have not decided what to do. I have a few things in mind (adding
> floating point support, removing overlaps [skip]

If I understand correctly, overlaps cause unexpected discontinuity in
SDF, which otherwise should not have any. I doubt that detecting and
removing contour overlaps is productive. I would rather deal with the
discontinuity directly. Perhaps there is a clever way to ignore
smaller distances that unexpectedly have an opposite sign. The
distance cannot change by more than the grid size. If it does, ignore
the offending value.

> CascadiaCode.ttf

Oh those variable fonts with overlaps...  When you read
https://docs.microsoft.com/en-us/typography/opentype/spec/glyf#simpleGlyphFlags
on OVERLAP_SIMPLE, there is a glimmer of hope: "either set this flag
in the derived glyph data, or else should merge contours to remove
overlap". So the flag is basically required in static fonts. I hope it
will be required in variable fonts too in the next version of specs.

Alexei

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

[Anuj Verma]

Hello Werner, Alexei,

I have mostly completed the bitmap to SDF renderer (bsdf), there
are only a few things remaining such as support for all pixel
modes (currently it only work with FT_PIXEL_MODE_GRAY),
and warnings etc. I did say before that the bitmap to SDF will require
less memory than the other, but that is not the case, after I read the
algorithm and implemented it, both the renderers have similar memory
requirements. The only advantage of the  bsdf renderer is that it can
handle glyphs with overlaps.

Next, I will be finishing the bsdf renderer and then writing the
documentation
for all the functions (should I write for structs as well? i.e. detailed
description
of all the members). Also is there any other kind of documentation that I
should
add ?
After that I have not decided what to do. I have a few things in mind
(adding
floating point support, removing overlaps and a few more). But we can
discuss
that once I have finished the documentation. (Also, I will keep improving
the
existing algorithms, optimizing and removing any bug that I find along the
way)

I have updated the demo (https://github.com/preversewharf45/ft2sdf-demo)
and this time I have added the help screen ('?' or F1), I have also included
a font `CascadiaCode.ttf' which is full of overlaps, so that you can compare
both the renderers.

Thanks,
Anuj

Re: GSOC Build tests

[Werner LEMBERG]

>> This looks very good, thanks!  Indeed, the archive size of almost
>> one Gigabyte is far too large for practical purposes.  We have now
>> to find solutions in the next month how to refine that.
> 
> Right now it runs ~12 fonts that have ~3k glyphs each; this is why
> it's so large.  I think the best solution is splitting up runs of
> the tests to limit it to specific fonts and glyph ranges.  That way
> you can download the smaller subset of tests that fail.

Yes.

>> What do you think about using a control file that specifies which
>> fonts to use, which glyphs in those fonts to use at which sizes,
>> modes, etc.?
> 
> The scripts are already basically structured to do this so adding
> that should be easy.  If you could give me an idea of how you would
> like the config file structured I can write a parser easily enough.

I guess people would use YAML syntax for that today; this saves you
writing a parser by your own.

On the other hand, YAML can't be easily parsed with shell scripts – if
necessary, don't hesitate to use a script language (Python, Perl,
etc., it's basically up to you).

>> I think some CSS magic to make the results more pleasing would also
>> be nice, but this is an extra of no particular importance
>> currently.
> 
> I've never been the best at design.  If someone can give me a design
> mockup or something similar they'd like it to look to though I can
> make it match fairly easily.

OK, let's delay this then.

> Here is a small subset of the glyphs. I've manually modified one in
> gimp to show the image diffing.
> https://drive.google.com/file/d/1Y5MZ1laLK0UrZyCxbYIq3sptFDIfhoSg/view?usp=sharing

Thanks.  However, after unpacking and clicking on

  ft-tests
  → index.html
  → ft-LiberationSerif-Regular.ttf-16-report
  → ftgrid_0002.png

(which links to `ftgrid_0002.html`), I get an empty page.

Looking around I've found the difference png – what do you think of
slightly coloring the differences?  And for comparing B/W images, I
remember that I've coloured points only in the reference image as
green and in the new image as red...


Werner

Re: GSOC Build tests

[Greg Williamson]

> This looks very good, thanks!  Indeed, the archive size of almost one
> Gigabyte is far too large for practical purposes.  We have now to find
> solutions in the next month how to refine that.

Right now it runs ~12 fonts that have ~3k glyphs each; this is why it's so
large. I think the best solution is splitting up runs of the tests to limit
it to specific fonts and glyph ranges. That way you can download the
smaller subset of tests that fail.

> What do you think about using a control file that specifies which
> fonts to use, which glyphs in those fonts to use at which sizes,
> modes, etc.?

The scripts are already basically structured to do this so adding that
should be easy. If you could give me an idea of how you would like the
config file structured I can write a parser easily enough.

> I think some CSS magic to make the results more pleasing would also be
> nice, but this is an extra of no particular importance currently.

I've never been the best at design. If someone can give me a design mockup
or something similar they'd like it to look to though I can make it match
fairly easily.

> The most important thing IMHO is that you (manually) prepare a subset
> of the large report now (not larger than, say, 1MByte) so that other
> interested persons can quickly download it to have a look.
> Additionally, it might be helpful if you could send some screen shots
> to the list.

Here is a small subset of the glyphs. I've manually modified one in gimp to
show the image diffing.
https://drive.google.com/file/d/1Y5MZ1laLK0UrZyCxbYIq3sptFDIfhoSg/view?usp=sharing

Here are some images:
https://imgur.com/cBTwrDr.png
https://imgur.com/uCx2xOI.png
https://imgur.com/hPtWmJI.png
https://imgur.com/AyRMA92.png


On Thu, Jul 30, 2020 at 4:39 AM Werner LEMBERG  wrote:

>
> > I've finished the core of the regression tester.
>
> Great!
>
> > You can now run it and generate a html report but you will need a
> > few tools installed: imagick, xwd, npm, pretty-diff and xvfb.  This
> > should all be listed in ft-regression.sh's comments.If you want to
> > run it locally make sure you have a ~/test-fonts with .ttf files in
> > it.
>
> Thanks; I will try that in the next few days, hopefully.
>
> > This is basically what I wanted to accomplish for my GSOC project
> > but I can do a lot of the things mentioned in my previous message if
> > I pass my evaluation.
>
> :-)
>
> > You can download the report it generates from here:
> >
> https://dev.azure.com/fundies/9eabb07a-6a4d-4b68-b22e-60f9e02c1927/_apis/build/builds/232/artifacts?artifactName=Archlinux%20Regression%20tests=5.1&%24format=zip
> > The file is rather large.  In the future, I could probably shrink it
> > quite a bit by using 7zip instead of regular zip or I could split
> > the tests into smaller chunks too.
>
> This looks very good, thanks!  Indeed, the archive size of almost one
> Gigabyte is far too large for practical purposes.  We have now to find
> solutions in the next month how to refine that.
>
> What do you think about using a control file that specifies which
> fonts to use, which glyphs in those fonts to use at which sizes,
> modes, etc.?
>
> I think some CSS magic to make the results more pleasing would also be
> nice, but this is an extra of no particular importance currently.
>
> > The report doesn't demonstrate the image comparison because there
> > are obviously no regressions between my commit and master.  However,
> > if there is one it will generate a page where you can see the
> > differences between images on mouse over.  For text files it
> > generates a diff report using pretty-diff. You can see this in the
> > freetype-bench comparisons.
>
> I *have* to see the image comparison live :-) When testing this
> locally, I'll try to temporarily introduce a bug – since this depends
> on the selected fonts I also have to do some trial and error to find a
> good spot to do that.
>
> > As I've said this should be mostly working now. I also believe I've
> > commented the source pretty thoroughly.  I've also moved the scripts
> > to a subdir as requested.  If there are any changes / improvements
> > you would like to see to the reports or scripts please let me know.
> > If not, I have listed several things I would like to do to polish it
> > in my previous message.
>
> The most important thing IMHO is that you (manually) prepare a subset
> of the large report now (not larger than, say, 1MByte) so that other
> interested persons can quickly download it to have a look.
> Additionally, it might be helpful if you could send some screen shots
> to the list.
>
>
> Werner
>

Re: GSOC Build tests

[Werner LEMBERG]

> I've finished the core of the regression tester.

Great!

> You can now run it and generate a html report but you will need a
> few tools installed: imagick, xwd, npm, pretty-diff and xvfb.  This
> should all be listed in ft-regression.sh's comments.If you want to
> run it locally make sure you have a ~/test-fonts with .ttf files in
> it.

Thanks; I will try that in the next few days, hopefully.

> This is basically what I wanted to accomplish for my GSOC project
> but I can do a lot of the things mentioned in my previous message if
> I pass my evaluation.

:-)

> You can download the report it generates from here:
> https://dev.azure.com/fundies/9eabb07a-6a4d-4b68-b22e-60f9e02c1927/_apis/build/builds/232/artifacts?artifactName=Archlinux%20Regression%20tests=5.1&%24format=zip
> The file is rather large.  In the future, I could probably shrink it
> quite a bit by using 7zip instead of regular zip or I could split
> the tests into smaller chunks too.

This looks very good, thanks!  Indeed, the archive size of almost one
Gigabyte is far too large for practical purposes.  We have now to find
solutions in the next month how to refine that.

What do you think about using a control file that specifies which
fonts to use, which glyphs in those fonts to use at which sizes,
modes, etc.?

I think some CSS magic to make the results more pleasing would also be
nice, but this is an extra of no particular importance currently.

> The report doesn't demonstrate the image comparison because there
> are obviously no regressions between my commit and master.  However,
> if there is one it will generate a page where you can see the
> differences between images on mouse over.  For text files it
> generates a diff report using pretty-diff. You can see this in the
> freetype-bench comparisons.

I *have* to see the image comparison live :-) When testing this
locally, I'll try to temporarily introduce a bug – since this depends
on the selected fonts I also have to do some trial and error to find a
good spot to do that.

> As I've said this should be mostly working now. I also believe I've
> commented the source pretty thoroughly.  I've also moved the scripts
> to a subdir as requested.  If there are any changes / improvements
> you would like to see to the reports or scripts please let me know.
> If not, I have listed several things I would like to do to polish it
> in my previous message.

The most important thing IMHO is that you (manually) prepare a subset
of the large report now (not larger than, say, 1MByte) so that other
interested persons can quickly download it to have a look.
Additionally, it might be helpful if you could send some screen shots
to the list.


Werner

Re: GSOC Build tests

[Greg Williamson]

I've finished the core of the regression tester. You can now run it and
generate a html report but you will need a few tools installed: imagick,
xwd, npm, pretty-diff and xvfb. This should all be listed in
ft-regression.sh's comments.If you want to run it locally make sure you
have a ~/test-fonts with .ttf files in it. You will also need freetype2 and
freetype2-demos sources next to each other. You can run it locally by
calling: ./CI/ft-regression.sh  eg: ./CI/ft-regression.sh HEAD~1
from inside your freetype2 directory. It should generate an easy to digest
report to /tmp/ft-tests/index.html. This is basically what I wanted to
accomplish for my GSOC project but I can do a lot of the things mentioned
in my previous message if I pass my evaluation.

I've also got the testing apparatus running on azure pipelines with the
other tests here:
https://dev.azure.com/fundies/freetype2/_build/results?buildId=232=results

Ignore the mingw build failures as they seem to be in the midst of a regime
change and their new signed key databases aren't in sync with azure.

You can download the report it generates from here:
https://dev.azure.com/fundies/9eabb07a-6a4d-4b68-b22e-60f9e02c1927/_apis/build/builds/232/artifacts?artifactName=Archlinux%20Regression%20tests=5.1&%24format=zip
The file is rather large. In the future, I could probably shrink it quite a
bit by using 7zip instead of regular zip or I could split the tests into
smaller chunks too.
The report doesn't demonstrate the image comparison because there are
obviously no regressions between my commit and master. However, if there is
one it will generate a page where you can see the differences between
images on mouse over. For text files it generates a diff report using
pretty-diff. You can see this in the freetype-bench comparisons.

As I've said this should be mostly working now. I also believe I've
commented the source pretty thoroughly. I've also moved the scripts to a
subdir as requested. If there are any changes / improvements you would like
to see to the reports or scripts please let me know. If not, I have listed
several things I would like to do to polish it in my previous message.

Here is my patchset:
https://patch-diff.githubusercontent.com/raw/fundies/freetype2/pull/1.patch

On Tue, Jul 21, 2020 at 12:23 AM Werner LEMBERG  wrote:

>
> Hello Greg,
>
>
> > figured out the cause. I have however been working on this as much
> > as time allows. I've mostly hashed out the scripts to run regression
> > tests using demos here:
> >
> https://patch-diff.githubusercontent.com/raw/fundies/freetype2/pull/1.patch
> > [...]
>
> Some comments.
>
> * There are too much top-level files.  Please move them to
>   subdirectories.
>
> * Please submit patches to the list that are generic enough to be
>   included into 'master'.  This affects the CMake stuff, for example.
>
> * If possible, don't use lines longer than 80 characters.
>
> * Please avoid trailing whitespace.
>
> > . The scripts still need a bit of work.  I've only just started the
> >   bits that generate a html report for devs to inspect and I need to
> >   hook it into azure pipelines.
>
> My problem is that I have zero knowledge of azure.  So please...
>
> > A couple other issues I want/plan to address are:
> >
> > 1. I need to comment the scripts better
>
> ... do that in the first place.
>
> > 2. I need to add a script argument to specify the demos commit as
> >not all commits of freetype2 are compatible with freetype2-demos
> >(in fact this broke on me over the past couple weeks)
>
> Normally, 'freetype2' and 'freetype2-demos' stay in sync date-wise.
> What about using the date of a given 'freetype2' commit to get a
> corresponding commit in 'freetype2-demos'?
>
> > 3. I currently run the demos in xvfb ...
>
> Isn't `xvfb` going to be replaced with `xf86-video-dummy`?
>
> >... but this isn't exactly compatible with windows so if you wish
> >for the regression test to run there I might need to modify some
> >the demos to just dump an image without opening a window
>
> This might be generally useful, yes.  However, I suggest that you
> concentrate on having the tests first.  It is rather unlikely that
> FreeType itself behaves differently on Windows since it is quite
> generic C code with only a very small amount of platform-specific
> code.  In other words, getting screenshots of running FreeType demo
> tools on Windows makes sense to catch problems in the GUI code of the
> tools but probably not of the FreeType library.  For the time being I
> think it is sufficient to have Windows compilation tests.
>
> > 4. I don't see a clear way to get the number of characters in a font
> >using any of the existing demos so I might need to add a utility
> >for that but for now I just hardcode those values in each font
> >test
>
> Please be careful with terminology: In general, you count the numbers
> of *glyphs* in a font.  The number of character codes is strongly
> dependent on a font's 

Re: GSOC Build tests

[Werner LEMBERG]

Hello Greg,


> figured out the cause. I have however been working on this as much
> as time allows. I've mostly hashed out the scripts to run regression
> tests using demos here:
> https://patch-diff.githubusercontent.com/raw/fundies/freetype2/pull/1.patch
> [...]

Some comments.

* There are too much top-level files.  Please move them to
  subdirectories.

* Please submit patches to the list that are generic enough to be
  included into 'master'.  This affects the CMake stuff, for example.

* If possible, don't use lines longer than 80 characters.

* Please avoid trailing whitespace.

> . The scripts still need a bit of work.  I've only just started the
>   bits that generate a html report for devs to inspect and I need to
>   hook it into azure pipelines.

My problem is that I have zero knowledge of azure.  So please...

> A couple other issues I want/plan to address are:
> 
> 1. I need to comment the scripts better

... do that in the first place.

> 2. I need to add a script argument to specify the demos commit as
>not all commits of freetype2 are compatible with freetype2-demos
>(in fact this broke on me over the past couple weeks)

Normally, 'freetype2' and 'freetype2-demos' stay in sync date-wise.
What about using the date of a given 'freetype2' commit to get a
corresponding commit in 'freetype2-demos'?

> 3. I currently run the demos in xvfb ...

Isn't `xvfb` going to be replaced with `xf86-video-dummy`?

>... but this isn't exactly compatible with windows so if you wish
>for the regression test to run there I might need to modify some
>the demos to just dump an image without opening a window

This might be generally useful, yes.  However, I suggest that you
concentrate on having the tests first.  It is rather unlikely that
FreeType itself behaves differently on Windows since it is quite
generic C code with only a very small amount of platform-specific
code.  In other words, getting screenshots of running FreeType demo
tools on Windows makes sense to catch problems in the GUI code of the
tools but probably not of the FreeType library.  For the time being I
think it is sufficient to have Windows compilation tests.

> 4. I don't see a clear way to get the number of characters in a font
>using any of the existing demos so I might need to add a utility
>for that but for now I just hardcode those values in each font
>test

Please be careful with terminology: In general, you count the numbers
of *glyphs* in a font.  The number of character codes is strongly
dependent on a font's cmaps.  So I guess you want to know the number
of glyphs, right?

`ftdump` shows a 'glyph count' line.  Maybe this works for you.
Alternatively, a small tool to explicitly get this value should be
easy to write.

> 5. I'm not sure ftgrid and etc support all render modes?

Mhmm, maybe.  With `ftgrid`, for example, use keys 'F5' and 'F6' to
cycle through rendering modes.

Alexei, how do I specify keys like 'F5' with the `-k` command line
option?

> I'm currently working on the report generation as well as 1/2 and
> hope to have something to show soon.  However, to show results it
> would be helpful if someone could point me to a line of code I could
> tweak to subtly break rendering between commits so we can see it
> find faults.

It's not clear to me what you want to achieve.  Please elaborate.

> Also, if there are already any solutions to my issues with demos
> I've missed please let me know so I don't reinvent the wheel.

If my explanations above are not sufficient please don't hesitate to
ask more!


Werner

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

[Werner LEMBERG]

> I have my college exams on 23rd and 24th this month, and as I
> haven't prepared for them yet, I would like to give a few days that
> are left and study for my exams.

Of course.  I wish you success!


Werner

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

[Anuj Verma]

Hello Alexei, Werner,

I have my college exams on 23rd and 24th this month,
and as I haven't prepared for them yet, I would like to
give a few days that are left and study for my exams.
My last exam is on the 24th morning and after that I will
start doing the bitmap to SDF renderer which I think
will not take more than 2 weeks.

Thanks,
Anuj

Re: GSOC Build tests

[Greg Williamson]

Hi, sorry for lack of responses. I have been very busy with final projects
for my summer classes and to top it off, some of the ram (or slots on the
motherboard) in my computer died and my computers were super wonky until I
figured out the cause. I have however been working on this as much as time
allows. I've mostly hashed out the scripts to run regression tests using
demos here:
https://patch-diff.githubusercontent.com/raw/fundies/freetype2/pull/1.patch
. The scripts still need a bit of work. I've only just started the bits
that generate a html report for devs to inspect and I need to hook it into
azure pipelines. A couple other issues I want/plan to address are:

1. I need to comment the scripts better
2. I need to add a script argument to specify the demos commit as not all
commits of freetype2 are compatible with freetype2-demos (in fact this
broke on me over the past couple weeks)
3. I currently run the demos in xvfb but this isn't exactly compatible
with  windows so if you wish for the regression test to run there I might
need to modify some the demos to just dump an image without opening a window
4. I don't see a clear way to get the number of characters in a font using
any of the existing demos so I might need to add a utility for that but for
now I just hardcode those values in each font test
5. I'm not sure ftgrid and etc support all render modes?

I'm currently working on the report generation as well as 1/2 and hope to
have something to show soon. However, to show results it would be helpful
if someone could point me to a line of code I could tweak to subtly break
rendering between commits so we can see it find faults. Also, if there are
already any solutions to my issues with demos I've missed please let me
know so I don't reinvent the wheel.

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

[Alexei Podtelezhnikov]

Hi Anuj

> Which one do you think is better ? I prefer the second one i.e. adding
> another renderer within the `sdf' module. That way I can share some
> of the code, whereas creating another module will require me to
> rewrite everything.

Same module with two renderers as you described makes sense to me too.

Alexei

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

[Anuj Verma]

 >> * `FT_Lookup_Renderer' uses renderer format which is currently
>>   `FT_GLYPH_FORMAT_OUTLINE' for the `sdf' module.  How can
>>make it accept both outline and bitmap glyph format ?
>
> Regarding the second issue I think that you probably have to create a
> second renderer that shares most of the code with the original one.

So, I  started adding the new renderer module for the bitmap to sdf
conversion. Is that okay? i.e. adding a new module named `sdfb'.
Or should I just create another renderer in the same module
and add it to the `module.mk' ? something like this:

```
FTMODULE_H_COMMANDS += SDF_RENDERER
FTMODULE_H_COMMANDS += SDF_BITMAP_RENDERER

define SDF_RENDERER
$(OPEN_DRIVER) FT_Renderer_Class, ft_sdf_renderer_class $(CLOSE_DRIVER)
$(ECHO_DRIVER)sdf   $(ECHO_DRIVER_DESC)signed distance field
renderer$(ECHO_DRIVER_DONE)
endef

define SDF_BITMAP_RENDERER
$(OPEN_DRIVER) FT_Renderer_Class, ft_sdf_bitmap_renderer_class
$(CLOSE_DRIVER)
$(ECHO_DRIVER)sdfb  $(ECHO_DRIVER_DESC)bitmap to signed distance field
converter$(ECHO_DRIVER_DONE)
endef

#EOF
```
Which one do you think is better ? I prefer the second one i.e. adding
another renderer within the `sdf' module. That way I can share some
of the code, whereas creating another module will require me to
rewrite everything.

Thanks,
Anuj

On Wed, Jul 15, 2020 at 10:43 AM Werner LEMBERG  wrote:

>
> > I have added all the optimization modes to the module.
>
> Great, thanks!
>
> > By far the fastest method is to subdivide the curve into a number of
> > line segments.  [...]
>
> OK.  I'm glad that you took the time to implement the various
> algorithms so that we have such a comparison.
>
> > The major downside of the BB and subdivision methods is that they
> > require a considerable amount of memory usage (almost 3x of the size
> > of bitmap) because we need to keep a track of the distances and
> > signs of all the grid points.
>
> I don't think this is an issue.  For other rendering modes like LCD
> there are similar requirements, and platforms that are going to use
> SFDs certainly have plenty of memory.  It would be nice, however, if
> you can add this constraint to the documentation, and, if possible,
> also add a logging message that either predicts the necessary
> (approximate) amount of memory before the computation, and/or the
> actual memory use after generating an SFD.
>
> > I have updated the demo, added bilinear filtering, shape
> > reconstruction and has all optimization modes which can be toggled.
> > I have attached the new list of keys.
> > (https://github.com/preversewharf45/ft2sdf-demo)
>
> Thanks, will test soon.
>
> > For now I would like to hold the outline implementation for now and
> > go to the bitmap implementation.  After that the module can be used
> > to generate SDF from bitmaps directly.  It will be pretty fast and
> > will not require any additional memory other than the bitmap itself
> > at a cost of reduced accuracy.
>
> Excellent.
>
> > However there are a few issues.
> >
> > * `FT_Render_Glyph_Internal' break if the glyph format is already
> >a bitmap.
> >```
> > case FT_GLYPH_FORMAT_BITMAP:   /* already a bitmap, don't do
> anything */
> >   break;
> >```
> > * `FT_Lookup_Renderer' uses renderer format which is currently
> >   `FT_GLYPH_FORMAT_OUTLINE' for the `sdf' module.  How can
> >make it accept both outline and bitmap glyph format ?
> >
> > I don't like the idea of changing the internals of freetype so is
> > there any other way in which this can be done ?
>
> Don't worry about changing the internals!  You know best what to do,
> and we can discuss later whether your solution is the right approach.
> Regarding the second issue I think that you probably have to create a
> second renderer that shares most of the code with the original one.
> Alexei?
>
>
> Werner
>

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

[Alexei Podtelezhnikov]

> On Jul 16, 2020, at 00:42, Werner LEMBERG  wrote:
> 
> 
>>> I would be less worried about FT_Property_Set if FreeType reserved
>>> the right to remove (ignore) or change properties when it is
>>> reasonable to do so, i.e. properties should not be considered a
>>> part of API.
>> 
>> Does that mean I shouldn't use `FT_Property_Set' ? For some
>> parameters such as `spread' there is no other way to dynamically set
>> it.
> 
> You definitely should use `FT_Property_Set`.  However, as done in
> other modules, we declare (some of) the properties as 'experimental'
> in the documentation so that we can change or remove them if
> necessary.

Yes. For example, the spread probably defines the range of reliable 
interpolations. So this option is solidly user-relevant. The algorithm, on the 
other hand is a developer option to experiment with. A user should not expect 
this option to be perpetually available as new algorithms might be offered and 
the old ones dropped. Perhaps, a development option is a better name.

Alexei

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

[Werner LEMBERG]

>> I would be less worried about FT_Property_Set if FreeType reserved
>> the right to remove (ignore) or change properties when it is
>> reasonable to do so, i.e. properties should not be considered a
>> part of API.
> 
> Does that mean I shouldn't use `FT_Property_Set' ? For some
> parameters such as `spread' there is no other way to dynamically set
> it.

You definitely should use `FT_Property_Set`.  However, as done in
other modules, we declare (some of) the properties as 'experimental'
in the documentation so that we can change or remove them if
necessary.


Werner

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

[Anuj Verma]

Hello Alexei,

> Ok to remove. This only optimizes mistaken calls to FT_Render_Glyph on
> bitmap fonts. A related question is whether we need FT_LOAD_TARGET_SDF
> for FT_Load_Glyph?

I don't think we need `FT_LOAD_TARGET_SDF', I much prefer loading it with
`FT_LOAD_DEFAULT' and then rendering it separately. However to keep it
consistent with the rest of the renderers we might need to add it.

> I would be less worried about FT_Property_Set if FreeType reserved the
> right to remove (ignore) or change properties when it is reasonable to
> do so, i.e. properties should not be considered a part of API.

Does that mean I shouldn't use `FT_Property_Set' ? For some parameters
such as `spread' there is no other way to dynamically set it.

Anuj

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

[Alexei Podtelezhnikov]

Hi Anuj,

> > Alexei?
>
> Okay, I will probably only need to remove this case statement.
> ```
> case FT_GLYPH_FORMAT_BITMAP:   /* already a bitmap, don't do anything */
>break;
> ```

Ok to remove. This only optimizes mistaken calls to FT_Render_Glyph on
bitmap fonts. A related question is whether we need FT_LOAD_TARGET_SDF
for FT_Load_Glyph?

Indeed, the bitmap-to-sdf renderer should be separate as it hardly
shares anything.

I would be less worried about FT_Property_Set if FreeType reserved the
right to remove (ignore) or change properties when it is reasonable to
do so, i.e. properties should not be considered a part of API.

Alexei

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

[Anuj Verma]

 > I don't think this is an issue.  For other rendering modes like LCD
> there are similar requirements, and platforms that are going to use
> SFDs certainly have plenty of memory.  It would be nice, however, if
> you can add this constraint to the documentation, and, if possible,
> also add a logging message that either predicts the necessary
> (approximate) amount of memory before the computation, and/or the
> actual memory use after generating an SFD.

Alright, I will add a log message about the exact memory used after
generating the SDF. Is there any profiling tool built into FreeType?
If there is the exact time can be logged as well.

> Don't worry about changing the internals!  You know best what to do,
> and we can discuss later whether your solution is the right approach.
> Regarding the second issue I think that you probably have to create a
> second renderer that shares most of the code with the original one.
> Alexei?

Okay, I will probably only need to remove this case statement.
```
case FT_GLYPH_FORMAT_BITMAP:   /* already a bitmap, don't do anything */
   break;
```
And yeah I like the idea of creating a seperate renderer, since it won't
be used much. The only cases I can think of where SDF from bitmap
will be generated is either for bitmap fonts or for glyphs with overlapping
contours( until I add something to remove the overlapps ). So, if it is a
separate module it can easily be disabled.

>> I have updated the demo, added bilinear filtering, shape
>> reconstruction and has all optimization modes which can be toggled.
>> I have attached the new list of keys.
>> (https://github.com/preversewharf45/ft2sdf-demo)
>
> Looks excellent!  Some items for the wishlist of `ftstd`:
>
> * A help menu showing the list of keys.
>
> * Easy navigation to get to large glyph indices easily.

I will later create the demo from scratch, so will add these.

> * It probably makes sense to not allow 'Width' values in
>   reconstruction mode to be larger than '(Spread - 1)' or something
>   similar, emitting a warning if this threshold is reached.  Otherwise
>   you get white boxes without a warning.

Yeah, I forgot about that. The `Width' shouldn't exceed `(Spread - 1)'
Thanks for pointing that out, I will add this while creating the new demo.

Thanks,
Anuj

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

[Werner LEMBERG]

> I have updated the demo, added bilinear filtering, shape
> reconstruction and has all optimization modes which can be toggled.
> I have attached the new list of keys.
> (https://github.com/preversewharf45/ft2sdf-demo)

Looks excellent!  Some items for the wishlist of `ftstd`:

* A help menu showing the list of keys.

* Easy navigation to get to large glyph indices easily.

* It probably makes sense to not allow 'Width' values in
  reconstruction mode to be larger than '(Spread - 1)' or something
  similar, emitting a warning if this threshold is reached.  Otherwise
  you get white boxes without a warning.


Werner

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

[Anuj Verma]

 > what about adding the other two methods (or one of them) and decide
> which one to choose with an option of the build system ? So one method
> fast build consume more memory than other one which is slower.

Yes, even I thought about that. We can also keep both the methods
and use `FT_Property_Set' to switch between the two, which I am
currently using to compare performance.