Derek,
On Fri, May 31, 2024 at 2:23 PM Derek B. Noonburg
wrote:
> For what it's worth, I've encountered the same problem in a few PDF
> files. In all the cases I've seen, the OpenType file contains just the
> 'CFF ' table. My code checks for a missing 'head' table, and in that
> case it extracts
Hi Ahmet
Actually, src/ftgamma.c is the easiest app to follow with the least complicated
code. Let me know if you have questions.
Alexei
Hi Hin-Tak,
These macros were never used before. I fixed them. Now I think they
made the code less readable and I might revert to the old code.
Thanks,
Alexei
On Wed, May 22, 2024 at 6:12 PM Hin-Tak Leung
wrote:
>
> Actually it might be a good idea to stick CC=g++/clang++ as an additional job
> On May 20, 2024, at 04:54, Erin Melucci wrote:
>
> >_WINRT_DLL:…. /ZW
This option seems appropriate
https://learn.microsoft.com/en-us/cpp/porting/how-to-use-existing-cpp-code-in-a-universal-windows-platform-app?view=msvc-170
> is this always the case when compiling freetype for UWP?
Hi Ahmet,
Good to hear from you. I doubt that #ifdef TEST might be useful for
you. It has been a dead code for years. What is important is
understanding the basic workflow. Notice that the main() programs
eventually go into do-while(!Process_Event()) loop.
In other words they repeatedly
Apparently, WINAPI_FAMILY_GAMES is too new to use. Should we just check ifdef _WINRT_DLL?Alexei A Podtelezhnikov, PhDOn May 17, 2024, at 12:33, Alexei Podtelezhnikov wrote:Erin,We cannot use WINAPI_FAMILY_PARTITION(), because some other compilers might choke on it. Even old MSVC might
Windows 10 SDK: I didn't want to break the build for anyone out there using older headers.On Fri, May 17, 2024 at 5:17 PM Alexei Podtelezhnikov <apodt...@gmail.com> wrote:Hi Erin,
Just to confirm, you could compile FreeType for Xbox. The stuff in that ifdef was not necessary. Correct?
Alexe
Hi Erin,
Just to confirm, you could compile FreeType for Xbox. The stuff in that ifdef
was not necessary. Correct?
Alexei
> On May 17, 2024, at 10:25, Erin Melucci wrote:
>
>
> This is not the proper way to detect API availability but it's the
> least-distuprive change possible to fix
On Mon, May 6, 2024 at 2:12 PM Hin-Tak Leung
wrote:
> I have upgraded to fc40 last week, and there has been some breakage of
> skia-python against current skia lately, so I thought I'd update and rebuild
> the skia-enabled ft2-demos, now ported over to github CI against freetype git
> head.
On Sat, May 4, 2024 at 10:19 AM Sean McBride wrote:
> > Me too. We are talking about an API which opens a window and shows an
> > uncompressed pixel buffer in whatever language.Then it passes on
> > keystrokes, receives an updated pixel buffer, and updates the window with
> > it.
>
> Is that
>
> The main purpose of going through all this trouble is long-term
> reproducibility of our scientific publications/results.
Reproducibility is not equal to determinism.
Xlib uses XPutImage.
Windows uses SetDIBitsToDevice.
What does macOS use?
Forgot to mention window resize events…
Again the goal is to remove dependencies like XQuartz and make it work without
it. Adding Qt or Py dependencies is not a solution. Or this a different project.
> On May 2, 2024, at 10:37, Alexei Podtelezhnikov wrote:
>
>
>>
>&
> Am I missing some points?
Me too. We are talking about an API which opens a window and shows an
uncompressed pixel buffer in whatever language.Then it passes on keystrokes,
receives an updated pixel buffer, and updates the window with it.
We are talking about really basic window programming
Welcome back, Ahmet!
I look forward to working with you over the summer. We have a warm-up
month to chat about the project without any specific goals.
I suggest that you play with our demos using XQuartz backend, research
possible macOS native API and ask Suzuki some random questions about
it.
On Wed, May 1, 2024 at 7:11 PM Mohammad Akhlaghi wrote:
>
> Do you mean here?
>
> https://gitlab.freedesktop.org/freetype/freetype/-/tree/master/builds/unix
> ...
Please start at README and README.git or here:
https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/docs/INSTALL.UNIX
.
Alexei
> On Apr 12, 2024, at 07:58, Ahmet Göksu wrote:
>
>
> Hello Alexei,
>
> I wrote my proposal for the related project.
>
> Best,
> Goksu
> goksu.in
>> On Apr 12, 2024 at 13:41 +0300, Alexei Podtelezhnikov ,
>> wrote:
>> Excellent!
&
> I don't understand anything here.
It depends whether here is there.
> On Jan 22, 2024, at 12:45, Hin-Tak Leung wrote:
>
> FWIW, this seems to duplicate functionality in harfbuzz, and also a mere
> subset, for that matter?
On the other hand, the dysfunctional kerning API, which exists, is misleading.
Partial GPOS support to fulfill the API promise is not a
Understandably, you cannot edit files in place. You need an account on
gitlab.freedesktop.org and [fork] FreeType, which has been done 114
times already.
Alternatively, send your patch here with a good description.
Alexei
On Fri, Jan 19, 2024 at 9:03 PM David Saltzman wrote:
>
> Hi,
>
> I'd
>
> I think I agree with this - the spec should not bend on
> limitations/quirks/bugs in freetype. It isn't the role of the spec to
> recommend fonts to be built in with special "hints", just because one
> implementation, in its current state, can't render satisfactorily without
> those
> What you're suggesting, if I understand correctly, is that the existing flags
> available in the glyf implementation, and a new flag made available in the
> CFF2 implementation, be maintained not on the basis of whether a glyph has
> overlap, but by the designer based on whether the FreeType
> The 4-fold speed difference is not an optimization, it is a liability
which should be taken explicitly. Some overlaps at single points are not
that noticeable. Only long runs along the axes are bad. So I disagree with
default oversampling even for variation fonts.
Let me explain that not all
>
> CFF2 is released, has been for years. As far as I know there's no solid
> convention for ignoring unrecognized operators in a CharString, so this would
> be CFF2 minor 1 at best. Which would be years out in terms of support.
We can do it in days for FreeType, then it is a matter of
Why? The sequence 0x0c 0x40 is reserved and not used for example.
> I'm afraid the horse has left the barn as far as that goes.
>
> Skef
>
>> On 12/19/23 04:23, Alexei Podtelezhnikov wrote:
>> I would suggest that CFF2 invent a special charstring to mark overlaps
&g
Hi Behdad
>>
>>> Note that freetype does not use the overlap flags to determine the path
>>> fill rule (winding vs even-odd), it always uses winding for TT or CFF2
>>> variable fonts, as the spec mandates; the discussion here is about freetype
>>> using the (TT glyf only) overlap flags to
>
> Note that freetype does not use the overlap flags to determine the path fill
> rule (winding vs even-odd), it always uses winding for TT or CFF2 variable
> fonts, as the spec mandates; the discussion here is about freetype using the
> (TT glyf only) overlap flags to enable what Alexei
>
>>
>> It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a
>> CFF2 font. Whether that makes sense is one thing I'd like advice about.
>> There's currently no such code.
>
> I would suggest that CFF2 invent a special charstring to mark overlaps
> with FT_OUTLINE_OVERLAP only
> It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a
> CFF2 font. Whether that makes sense is one thing I'd like advice about.
> There's currently no such code.
I would suggest that CFF2 invent a special charstring to mark overlaps
with FT_OUTLINE_OVERLAP only when necessary.
> It seemed like the simplest answer to this was to mark all outlines
> extracted from a CFF2 font as FT_OUTLINE_OVERLAP, because there's no
> inexpensive method of detecting it. And so I added code to do that and
> verified it was heeded in ftsmooth.c -- but the ftgrid output didn't
> look any
Which file should I download for building freetype dll on Windows 11 Pro for use with Python?ubawurinna/freetype-windows-binaries: Windows binaries of FreeTypegithub.comBut if you insist on building it yourself, you should ask more specific question and describe your compilation tools.
>
> Both comments from Alex are wrong...
>
Yeah, I figured it out
> I have bindings for freetype 2.4.0 for Python. I dont understand why that:
Do you realize that this version is 13 years old? I recently saw a current
FreeType version in the anaconda environment. Just saying…
>
> AttributeError: module 'freetype' has no attribute 'Face'
>
> is coming from:
Hi Kelvin
If you only interested in subpixels shifts and intend to cache 3
positions, you can achieve using LCD rendering and
https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html#ft_library_setlcdgeometry.
It is apparent that LCD rendering is essentially 3 traditional
antialiased
Hi Anurag,
Would you like to try smooth_malloc branch for fun? I will announce it soon.
Alexei
> On Oct 3, 2023, at 17:33, Anurag Thakur
> wrote:
>
>
> Hi all,
>
> Here's a quick update on the project status:
>
> I have implemented the "preloading" optimization where FreeType can perform
>
> Wanted to point out that compiling with gcc and adding "-stack-usage=2000" to
> get reports about stacks larger than 2000 bytes is probably the easiest way
> to track down large stacks at the moment. Note that
> af_cjk_metrics_init_widths (44480 bytes) and af_latin_metrics_init_widths
>
>> I will try the dynamic heap allocations for the rendering
>> buffer. This might be the largest of them, I think. In addition,
>> this should help with the rendering speed when rendering complex
>> shapes like
>> https://fonts.google.com/specimen/Cabin+Sketch. Currently, FreeType
>> makes
e would be
> happy if FreeType reduced the size of these stack frames.
>
> On Wed, Aug 30, 2023, 11:20 PM Alexei Podtelezhnikov
> wrote:
>>
>> Hi folks,
>>
>> Found this patch from ReactOS
>> https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/3
Hi folks,
Found this patch from ReactOS
https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/3rdparty/freetype/freetype_ros.diff
Do you understand why they are so averse to large stack allocations?
Thanks,
Alexei
> As long as v38 is different from v40, some part of it is closer than v40 to
> MS/Apple's. Also fact.
Also.. You are making it sound like we are handicapping FreeType. Then
Phoronix or Slashdot will sensationalize it. OMG! OMG! OMG! Major
FreeType regression!
This is FUD! This is zero evidence
> "Better" is your personal opinion. Anyway, I think some of others' "personal
> opinion" (different from yours) is simply based on familiarity - some people
> are just more familiar with MS/Apple rendering, and therefore prefer it. In
> the end of the day, FreeType is not MS/Apple font scaler.
Hi Hin-Tak
On Fri, Aug 18, 2023 at 2:06 PM Hin-Tak Leung
wrote:
> I see the infinality patch is already gone (next release, 2.13.2 I guess -
> bits of it was removed in 2.13.1 already).
Infinality (v38) was substituted by v40 in 2.13.1. Anybody requesting
v38 got v40 instead... and nobody even
> > ... calculate an "average" baseline and align to that ...
> Or align to the midpoints of the overall font glyph boxes (including
> font ascent and font descent). That may be a suitable compromise.
Or... whatever works. FreeType provides a client with all kinds of
metrics and bounding boxes,
> When using mono mode, the bitmap is rendered in big endian format where the
> most significant bit is the leftmost pixel, while in default mode the
> bitmap is rendered in little endian, consistent with my cpu.
This is documented
> Probably both approaches are wrong. I am asking that question both in terms
> of the spec and in terms of implementation details - what is the
> correct/recommended approach to render multi-layered 32-bit RGBA COLRv1 data
> to a non-colour target media?
My recommendation is to blend three
> > Hin-Tak,
>
> > This is probably both a spec question & a technical question. What is the
> > recommendation for COLRv1 when the rendering target media is not capable of
> > color?
>
>
> > Are you asking about RGB to gray conversion? There are multiple specs with
> > slightly different
Hin-Tak,
> This is probably both a spec question & a technical question. What is the
> recommendation for COLRv1 when the rendering target media is not capable of
> color?
Are you asking about RGB to gray conversion? There are multiple specs with
slightly different formulas and barely
Hin-Tak,
SVG rendering is handled by librsvg. If that buffer does not have correct
dimensions set, you might have all kinds of crashes. Therefore, try updating
that library. You might have a faulty version.
Alexei
> Hmm. Then `ftview`'s default cache size should probably be increased
> to cover both the number of characters/glyphs in Arabic and Indic
> scripts, including (most of) the necessary ligatures. If I call
> `ftview ArefRuqaaInk-Regular.ttf`, a bit more than 200 glyphs are
> shown; IMHO this
On Sun, May 14, 2023 at 9:08 AM Werner LEMBERG wrote:
>
> >> it's an SVG color font, and `ftview` lacks caching support for that
> >> AFAICS.
> >
> > With the most-recent-used logic, caching does not do much for ftview
> > when it outputs every different glyph once.The SVG speed is out of
> > our
> it's an SVG color font, and `ftview` lacks
> caching support for that AFAICS.
With the most-recent-used logic, caching does not do much for ftview
when it outputs every different glyph once.The SVG speed is out of our
hands.
Suzuki,
> Currently, my patch cares only FT_Face->num_glyphs
> for the face loaded by the t1cid driver. Do you
> concern as "the num_glyphs is no more than the
> declaration, there is no guarantee that the user
> can get a glyph image of the CID within the range
> 0...FT_Face->num_glyph,
rom GID to CID", to avoid 64kByte array allocation.
> > Then, when ftdump receives a font breaking this assumption,
> > ftdump aborts with an error, and indicates an email address
> > (or website?) to report the issue. Is it acceptable workaround?
> >
> > Regards,
&
Dear Suzuki,
> Indeed. If GID-CIDs are already sorted, it's easy to dump the
> available CIDs in a compressed syntax. Although I have no sample
> font including unsorted CIDs, I'm unsure whether it is required
> in some specifications.
The order of CIDs is in "registry, *ordering*, and
Dear Suzuki
> BTW, if the 64kByte array to check CID availability can be
> reduced to a 64kBit (= 8kByte for most architecture) array
> by a bitshift calculation, is it the way to go?
I agree that bitshift is too complicated. If the glyphs are sorted by
CID, you might not need the temporary
>> The execution "ftdump -c" for OpenType/CFF fonts with "holes" in the
>> implemented CIDs, like Hiragino fonts on macOS, generates the output
>> ending with:
>>
>> --
>> (...Charmap printout...),2f9de,2f9df,2f9f4
>>
>> /CIDSystemInfo dictionary
> Here is the 2nd revision,
>
> https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...c0267c89
>
> To dump the ROS info, it needs "-n" option, as it is needed to dump /FontInfo
> dictionary.
> For the similarity with /FontInfo dumping, the syntax of the output is
>
> ftdump is not a font debugger,
> but it would be much more helpful if it can dump the ROS info from
> OpenType/CFF.
I actually think that FreeType demos are the best font debugging tools out
there.
> My preliminary patch is
>
>> We encountered a few (potentially not fully compliant with the
>> specification) CFF fonts (i.e. CIDFontType0) that have enough
>> information to be rendered, but FreeType throws an exception due to
>> not having both the `head` and the `cmap` tables.
>
> Could you provide such a font for
>> * Usually pure greyscale (pixel) antialasing is way better for
>> me, but it also depends on whether the background is dark or
>> light and whether the rendering library applies the right
>> gamma correction for that
>
> Since many/most text setting libraries don't take this into
>
>> I have problem with all linux distros about fonts generally,
>> fonts are very smooth or fuzzy and it hurts my eyes when i
>> read more of the texts , [...] any patches to improve the
>> fonts to be like windows, very sharp
Since Windows is your gold standard, this is their tunable settings:
> > Since neither grep -E nor egrep is portable any more, here is a
> > patch that does essentially the same test as AC_PROG_EGREP for the
> > top-level configure. Can be overridden with the EGREP envvar.
>
> Applied, thanks!
Would sed be more portable here? The patterns are very easy here.
$
> /* UNDOCUMENTED! The MS rasterizer doesn't allow the following */
> /* graphics state variables to be modified by the CVT program. */
On Mon, Feb 13, 2023 at 3:50 PM Hin-Tak Leung
wrote:
> I think it is probably mis-documented - the projection vector and rp1 are not
> even
> >> > these new values.
> > You are looking at the outdated Apple's specifications. Please check
> > with OpenType 1.9 instead:
> > https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions#instruction-execution-control
> >
> > Specifically, "INSTCTRL[ ] can only be executed in
Sorry,
> > To establish a new default value for a graphics state variable, it is
> > necessary to change the value of that variable in the control value
> > program. Changes made in the control value program will apply to all
> > subsequently processed glyphs unless INSTCTRL[] is used to
> To establish a new default value for a graphics state variable, it is
> necessary to change the value of that variable in the control value
> program. Changes made in the control value program will apply to all
> subsequently processed glyphs unless INSTCTRL[] is used to inhibit
>
Hi All
> a, Aadjust axis 0
> b, Badjust axis 1
> ...
> p, Padjust axis 16
I’ve added a couple more interesting features to ftmulti after the release.
F3 now toggles the fill rule (even-odd) flag to reveal the overlaps in the
modern variation fonts.
F4 now toggles the
> a, Aadjust axis 0
> b, Badjust axis 1
> ...
> p, Padjust axis 16
Now you can collapse all these cases using:
axis = event. key - ‘A’;
Or
axis = event.key - ‘a’;
And make an alphabetical list on the screen.
A axis
B axis
C axis
>
> ```
> ? display this help screen
And F1 as commonly used for help
> q, ESC quit ftmulti
> F1 toggle axis grouping
See above, shift by one
> F2 toggle anti-aliasing
Might be a part of rendering mode cycle as in other demos.
> F3 toggle outline
> Can I suggest a more intuitive scheme?
> A,a to control axis 1
> B,b to control axis 2
> C,c to control axis 3
> and so on.
you can also list them "alphabetically":
A "GRAD": 0.0
B "XTRA": 562,00
which makes it super easy to find the appropriate control.
> I've just increased the number of handled axes in `ftmulti` from 6 to
> 15. Due to the new support of the 'avar' version 2 OpenType extension
> it is expected that the number of axes in many fonts will increase
> (after this extension gets accepted in the OpenType standard) because
> adding
Werner,
I got this. Ascender and Descender are optional and could either be
omitted or even set to zero in AFM, e.g. in the current URW++ base 35
fonts.
The fix is in.
Alexei
On Fri, Feb 3, 2023 at 12:35 PM Alexei Podtelezhnikov
wrote:
> Hi Werner,
>
> URW++ fonts are now distribu
Hi Werner,URW++ fonts are now distributed as t1 which is binary with an ASCII header. urw-base35-fonts/fonts at master · ArtifexSoftware/urw-base35-fontsgithub.comFreeType opens them just fine. There are also afm files. Do we need to attach them to t1? I tried but that messed up the ascender so it
https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/4028f9ac6a1e961bc33b55813398a31aca391d7e
Hi folks,
ftstring can now edit and display a simple ASCII string interactively,
press Enter.
Alexei
up to 2.10.2 I obtain the desired nice bitmap, with
> freetype since 2.10.3 (including the last 2.12.1) I obtain a different
> bitmap.
>
> My question is if it's possible with some parameter to obtain the "old"
> bitmap with freetype 2.12.1.
>
> Thank you
>
> Davide Rizzo
>
Davide,
> The new output is much worse, most of chars have single dots protruding
in the external outline.
We won't be able to help you unless you help us to reproduce or see
the issue. At the very least you should name the font and the size,
and give a screenshot. Also, in our mind, only bugs
On Wed, Dec 21, 2022 at 3:48 AM ricky rocky wrote:
> I saw an info that, can reduce 16kB -> 4kB, but I don't know if that will
> cause any bug when rendering.
Go ahead and try it. It is surprising for me that you cannot afford
16kB while you want TrueType fonts, which are typically >100kB.
On Tue, Dec 20, 2022 at 9:11 PM ricky rocky wrote:
> #define FT_RENDER_POOL_SIZE 16384L
>
> This definition is used in smooth/ftgrays.c/gray_convert_glyph() as a local
> buffer.
> For my small RAM chip, it is the large size.
You cannot spare 16kB for rendering. Alrighty. Or, do you want to
On Sun, Nov 6, 2022 at 10:34 PM Paul Sheer wrote:
>
> >
> > To be honest, I don't understand why he doesn't use blending with
> > gamma correction. It is not like an area of active research and
> > debate.
> >
>
> I have no idea what blending means in this context.
In essence, your 7/8 and 13/16
On Sun, Nov 6, 2022 at 12:01 PM Werner LEMBERG wrote:
>
>
> > I have pushed a new method to do terminal bold that seems to work
> > well. See screenshot.
> >
> > Basically I use a brightness of 7/8th for non-bold, and for bold a 1
> > pixel shadow of 13/16ths brightness. After hours of
Some of the differences that you highlight favor FreeType. Actually, most
of them favor FreeType over Windows.
Since you are talking about QImage, shouldn't you first ask them Qt?
If you are asking about the particular font, then you should examine the
font. We do have some tools like ftinspect
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
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 All,
We have a couple of Python2 scripts in src/tools. Would anybody volunteer to
upgrade them to Python3? Python2 is quickly disappearing from the Linux
distros. Particularly, glnames.py might be challenging. It is used to generate
src/psnames/psnames.h and implements a compression
> I really love freetype very much, so I want to make it more powerful and.
> Waiting for your plan.
I already told you that you have to reorganize your code into smaller
individual contributions. You have a nice list of changes. Each of the
list items has to be presented separately
> https://github.com/tsitcn/freetype2-taishan-improved
>
> Those improvements include:
> Outline:
> italic for any value.
> line thickness.
> Bitmap:
> Rotate for 4 directions.
> Italic. Three type: clockwise, counter-clockwise, top to bottom(chinese
> chars needthis feature).
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.
> 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
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
Hi Derek
> I'm attaching f2.cff.
Thanks. ‘ftlint 24 f2.cff’ is full of errors 0x0006. Do you mind filing an
issue on gitlab.freedesktop.org/freetype/freetype?
On Mon, Sep 5, 2022 at 1:12 PM Anurag Thakur
wrote:
> (notomono_comp.png)
> (notomono_comp_expanded.png)
These look very good indeed. The almost linear shape at the small
sizes comes from the dominant dependence on the glyph perimeter, more
or less. The convex shape apparent in the expanded
> On Sep 1, 2022, at 03:56, Anurag Thakur
> wrote:
>
> Version 2.6.5 is important because the original font-rs post is from 2016,
> which used 2.6.5 as the benchmark for comparison.
>
> The aim is to run FreeType 2.6.5 for benchmarking. Any help regarding this
> would be appreciated.
That
>
> I have found that FT_Get_Char_Index will explicitly return 0 for 'missing'
> characters which is the fix for the issue. I am using FT_Load_Char but should
> that really return a valid construct for an "invalid" character?
>
This is ridiculous. You are complaining about very basic
On Tue, Jul 26, 2022 at 12:55 AM Anurag Thakur <
anurag105cse...@bpitindia.edu.in> wrote:
> I cleaned up the code a bit and used `ftbench` to get performance numbers
> for the `smooth` and `dense` rasterizers.
> There is much room for improvement in the ported code, as can be clearly
> seen in
>
> The rasterizer is working now (albeit with some artefacts, image attached),
> but the code is in a very early stage and I'm working on cleaning it.
Your rasterizer has a problem with Bézier curves. Any algorithm starts with
flattening them or replacing with short straight segments. Then
Dear Hin-Tak,
> If it is all the same to you, I'd prefer it to say, but I guess I'll end up
> maintaining a revert in the FontVal fork. There is incentive in the FontVal
> backend to keep this, to match the Microsoft rastering backend.
I could not find any references to Infinality or
Dear FreeType community,
We have just committed a forewarning about Infinality removal.
- TrueType interpreter version 38 (aka Infinality) that was first
introduced about 10 years ago in FreeType 2.4.11 is now deprecated
and slated to be removed in the next version. TrueType
Dear FreeType community,
We have just committed a forewarning about Infinality removal.
- TrueType interpreter version 38 (aka Infinality) that was first
introduced about 10 years ago in FreeType 2.4.11 is now deprecated
and slated to be removed in the next version. TrueType
1 - 100 of 992 matches
Mail list logo
