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
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
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
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
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
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
>> 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):
>>
>>
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?
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
Hello Anurag,
what's the current state of your project? Please tell us what's going
on :-)
Werner
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
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
ect: 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
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
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.
> 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
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 difference
> 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
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 rasterize
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
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
> 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.
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
>> 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
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
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
> 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
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,
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
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
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
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
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
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
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
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
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
> [...] 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
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
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
>> 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
>
>> 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
> 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
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
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
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.
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
>
>
> 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
>
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
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
>
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
> 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
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.?
> 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.
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
>> [...] 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
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
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
>
> [...] 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
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
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
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
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.
> 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
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:
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:
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)
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
>> 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
>> 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
> 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
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
> 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
> 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.
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
> 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
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
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
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
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
> 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
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
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
>> 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
> 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
> 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
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
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
> 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
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
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
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
>> * `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
> 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
>> 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
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
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
> 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
> 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
> 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
1 - 100 of 278 matches
Mail list logo
