On Tue, May 14, 2019 at 11:24 PM Werner LEMBERG wrote:
>
> > If you read the OT-SVG table spec, multiple glyphs can refer to the
> > same SVG document. Then for a glyph eg. 1234, client is expected to
> > render the element with id "glyph1234" in the referenced SVG
> > document.
>
> OK, thanks.
On Tue, May 14, 2019 at 11:42 PM Werner LEMBERG wrote:
>
> > Realistically, not many fonts combine multiple glyphs into the same
> > SVG documents, for obvious reasons of workflow: fonts are built out
> > of a collection of standalone SVGs much more often than hand-curated
> > SVG documents
Alexei,
I don't know about others on the list. But I find the linear algebra /
bezier discussion very interesting and I'm happy to discuss those.
The new algorithm is pretty simple, yes. BTW, I wonder if the 1/8th of
pixel tolerance is what's causing this:
On Tue, May 14, 2019 at 8:37 AM Alexei Podtelezhnikov
wrote:
>
> > 3. *How much work to do make it work with FreeType*: Does it need a
>> >C API wrapper?
>>
>> Yes.
>
>
> Whatever external SVG renderer you choose, please use FT_Renderer facility
> to hook it up with FreeType instead of
On Tue, May 14, 2019 at 9:17 AM suzuki toshiya
wrote:
> Dear Behdad,
>
> Alexei wrote:
> > Whatever external SVG renderer you choose, please use FT_Renderer
> facility to hook it up with FreeType instead of creating a set of SVG
> specific functions: an SVG glyph should be tagged as
What happened to the resvg (Rust library) idea? At any rate, I agree SVG
renderrer should be pluggable by client and not fixed in FreeType.
Also, note that the small SVG Native comes at a cost that it doesn't
support much...
On Tue, May 7, 2019 at 8:27 AM wrote:
> On Tue, May 07, 2019 at
On Tue, May 7, 2019 at 9:46 AM Werner LEMBERG wrote:
>
> > What happened to the resvg (Rust library) idea?
>
> It's not completely off the table, but it seems to me that `svgnative'
> is preferable.
>
Given that we want a pluggable renderer, the whole discussion is moot. For
pangocairo, we're
Use cairo_image_surface_create_for_data().
On Fri, Jul 5, 2019 at 6:37 AM Moazin Khatri wrote:
> Hi,
>
> I'm trying to fix all of the memory leaks in the work that I have
> done so far and one very important memory leak is that of the whole
> image buffer data.
>
> For example, in my `resvg'
Hi Moazin,
That looks great.
You shouldn't be using global state though. The state should be held by
FT_Library and passed to init/fini as well as the renderer functions.
On Tue, Jul 2, 2019 at 10:03 PM Moazin Khatri
wrote:
> Hi Werner and Toshiya,
>
> While using resvg to render glyphs from
I haven't read the entire thread carefully. However I want to point out
that how the SVG library allocates and frees memory is its own business and
should NOT be tied to FreeType memory routines.
You still need to negotiate the bitmap allocation though.
On Sat, Jul 6, 2019 at 5:55 AM Moazin
I'm not sure what exactly points of discussion are, but in HarfBuzz we do
purposefully ignore position overflows. We use a macro like this for that:
#define HB_NO_SANITIZE_SIGNED_INTEGER_OVERFLOW
__attribute__((no_sanitize("signed-integer-overflow")))
If you want to copy the macro, please copy
On Fri, Jul 19, 2019 at 4:34 PM Moazin Khatri
wrote:
> Just want to express that this is very, *very*, /very/, VERY, bad.
>>
>
> Thank you for pointing that out. However, ...
>
> The whole property API is a big anti-pattern that FreeType has adopted.
>> Still, using it to set boolean, integer,
On Tue, Aug 20, 2019 at 11:35 AM Werner LEMBERG wrote:
>
> > [...], after this commit, I am not abusing it to set pointer to
> > code. I am abusing it to set a structure of four function pointers.
> >
> > Let me know if your concerns remain the same with this change.
>
> His concerns stay the
Why?
On Mon, Jul 29, 2019 at 12:41 PM Moazin Khatti
wrote:
> branch: GSoC-2019-moazin
> commit 8887048557db93857ffa6169cfe4c3190f9cb1a1
> Author: Moazin Khatti
> Commit: Moazin Khatti
>
> Performs basic to see if SVG data is valid or not.
> ---
> src/sfnt/ttsvg.c | 38
nvalid data is checked for and rejected, so decided to do
> the same.
>
> On Tue, Jul 30, 2019 at 12:59 AM Behdad Esfahbod
> wrote:
>
>> Why?
>>
>> On Mon, Jul 29, 2019 at 12:41 PM Moazin Khatti
>> wrote:
>>
>>> branch: GSoC-2019-moazin
&g
On Wed, Jul 17, 2019 at 8:37 AM Moazin Khatri
wrote:
> --with-svg=autoeither `yes' or `no', depending on what the
>> system provides
>>
>
> Werner, can you please elaborate what you mean by
> "what the system provides". I understood the rest of
> the options.
>
On Wed, Jul 17, 2019 at 6:00 AM Alexei Podtelezhnikov
wrote:
> > > Or, you can just prioritize the separate renderers. Do not waste
> > > your work.
> >
> > While the concept of having different renderers sounds nice in theory,
> > I think it is a hassle to implement, since it moves the burden
Just want to express that this is very, *very*, /very/, VERY, bad.
The whole property API is a big anti-pattern that FreeType has adopted.
Still, using it to set boolean, integer, or string values is justifiable.
Abusing it to set pointer to code, Just Unacceptable.
b
On Wed, Jul 17, 2019 at
You're not missing anything...
Face->GlyphSlot->Library...
On Thu, Jul 25, 2019, 4:47 AM Akira TAGOH wrote:
> Hi,
>
> FT_MM_Var instance can be created without FT_Library instance in its
> scope. but FT_Library is required to free it with FT_Done_MM_Var. How
> can it be freed to avoid the
Cairo has a "recording surface" which
has _cairo_recording_surface_get_bounds().
On Thu, Jul 25, 2019 at 2:43 PM Alexei Podtelezhnikov
wrote:
> Hi Moazin,
>
> Can any of SVG libraries return a bounding box without actual
> rendering? Do they have something for FT_RendererClass.get_glyph_cbox?
>
Hi,
I like to compose multiple glyphs in a bitmap without using any graphics
library. I found that FT_Bitmap_Blend() does exactly what I want except
that if none of the glyphs are color, it still promotes the image to a
color bitmap.
Would be nice to have another version that would only upgrade
Hi Werner,
On Thu, Nov 21, 2019 at 8:51 AM Werner LEMBERG wrote:
>
> Hello Behdad,
>
> > I like to compose multiple glyphs in a bitmap without using any
> > graphics library. I found that FT_Bitmap_Blend() does exactly what
> > I want except that if none of the glyphs are color, it still
> >
On Thu, Nov 21, 2019 at 3:15 PM Werner LEMBERG wrote:
>
> > I need these in my custom build setup. Looks correct to me.
>
> Will apply, thanks.
>
> However: The `aflatin2' stuff is never activated; I'm not sure whether
> it still compiles at all. What are you doing with it?
Right. I need to
I need these in my custom build setup. Looks correct to me.
Thanks
--
behdad
http://behdad.org/
diff --git a/src/autofit/aflatin2.c b/src/autofit/aflatin2.c
index c601ab8d9..dab86dde6 100644
--- a/src/autofit/aflatin2.c
+++ b/src/autofit/aflatin2.c
@@ -21,6 +21,7 @@
*/
+#include
Yes.
On Wed, Sep 25, 2019 at 1:38 PM Nikolaus Waxweiler
wrote:
> Hi list,
> I was just looking at SourceSerifVariable-Roman.otf from
> https://github.com/adobe-fonts/source-serif-pro/releases/tag/3.000R and
> found this discrepancy between the variable instance of Black and the
> static one
Hi David,
Thanks for bringing this up. I come from the GNOME camp. My understanding
is that meson is replacing autotools longterm, sidestepping attempts like
cmake, the same way that git replaced CVS, sidestepping mercurial, bazaar,
etc.
In the latest HarfBuzz release we added a meson build
Let me think about the HarfBuzz co-dependency a bit...
On Mon, May 18, 2020 at 12:26 PM Behdad Esfahbod wrote:
> Hi David,
>
> Thanks for experimenting with this!
>
> I encourage you to explore removing the Module and Service abstraction
> completely. We did that in Pango a c
Hi David,
Thanks for experimenting with this!
I encourage you to explore removing the Module and Service abstraction
completely. We did that in Pango a couple of years ago and never looked
back...
I'll reply to your original request this week. Threadsafety and lack of a
functional separate
On Sat, Aug 29, 2020 at 9:12 PM Anuj Verma wrote:
> Hello All,
>
> I have written the final report for my project.
>
> You can check it out here:
> https://gitlab.com/-/snippets/2007070
>
Thank you Anuj. I really enjoyed observing your work this summer, even
though I didn't get to contribute
Here's how HarfBuzz does it:
https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-blob.cc
On Sat, Aug 29, 2020, 10:33 AM Vincent Torri
wrote:
> On Sat, Aug 29, 2020 at 11:52 AM Werner LEMBERG wrote:
> >
> >
> > >> If this really makes a difference on Windows, and if you want to
> > >>
Hi David,
Thanks for the detailed response.
On Mon, Jun 29, 2020 at 5:07 PM David Turner wrote:
>
>
> Le dim. 28 juin 2020 à 04:19, Behdad Esfahbod a
> écrit :
>
>> Hi David,
>>
>> I've been meaning to reply to your request but the list of things I
>
On Tue, Jun 16, 2020 at 9:50 AM Werner LEMBERG wrote:
> >>> - Your handling of two edges meeting at a corner is solid. That's
> >>> exactly what we do in GLyphy. However, I'm also now convinced
> >>> that there is no way to produce SDF from contours that might
> >>> overlap. Imagine a
to generate
the output. But even solving computing roots or the Newton-Raphson can be
done in SIMD for up to 8 samples at a time.
On Tue, Jun 16, 2020 at 8:51 AM Behdad Esfahbod wrote:
> Hi Anuj,
>
> First, let me congratulate you. This is a very thorough and impressive
> p
Hi Anuj,
First, let me congratulate you. This is a very thorough and impressive
piece of work for such a short time period. I read your code over a week
ago but couldn't sit down and type this. I see there has been lots of
progress since. I'll just summarize:
- I highly suggest you stick to
On Tue, Jun 16, 2020 at 11:02 AM Werner LEMBERG wrote:
>
> > For SIMD, I studied what's available last year for HarfBuzz. I
> > documented what I found here:
> >
> > https://github.com/harfbuzz/harfbuzz/blob/simd/src/hb-simd.hh
>
> Thanks for the link, it's an interesting read.
>
> > If you
On Mon, Jun 15, 2020 at 9:47 AM Alexei Podtelezhnikov
wrote:
> On Mon, Jun 15, 2020 at 11:03 AM Anuj Verma wrote:
> >>
> > > For linear segments, it will save more than 90% according to your
> > > table. Then you will see that splitting Bezier curves is not such a
> > > bad option. In general,
Also I'm surprised that you haven't put the code get_min_distance code for
each edge type into a function. Would you prefer that I comment re these
on github?
On Tue, Jun 16, 2020 at 8:53 AM Behdad Esfahbod wrote:
> Oh, I forgot:
>
> After you do all this, you will realize that
On Tue, Jun 16, 2020 at 9:49 AM Alexei Podtelezhnikov
wrote:
> Anuj,
>
> Each curved segment has a large number of neighboring grid points.
> each of which has a unique nearest projection on the curve. The curve
> is naturally sampled by this projection points a very large number of
> times and
. This is what GLyphy does
and some of the other solutions as well.
On Tue, Jun 16, 2020 at 8:51 AM Behdad Esfahbod wrote:
> Hi Anuj,
>
> First, let me congratulate you. This is a very thorough and impressive
> piece of work for such a short time period. I read your code over a week
> ago b
On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG wrote:
>
> > I find it a *very* bad idea to have code in FreeType that would
> > write to a file. Specially bad if that can be controlled by an
> > env-var.
>
> Interesting. Please explain. Do you fear security issues?
>
> > I still think what's
On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG wrote:
>
> > I find it a *very* bad idea to have code in FreeType that would
> > write to a file. Specially bad if that can be controlled by an
> > env-var.
>
> Interesting. Please explain. Do you fear security issues?
>
Sorry, forgot to reply
Werner!
On Wed, Jun 17, 2020 at 12:23 AM Werner LEMBERG wrote:
> > Also, why doesn't FreeType use floats? Is it just because of
> > platform which doesn't have floating point type?
>
> Yes. The original intention of FreeType was to provide support for
> embedded devices, which usually are
Hi Anuj,
On Tue, Jun 16, 2020 at 9:43 PM Anuj Verma wrote:
> Hello Behdad,
>
> > First, let me congratulate you. This is a very thorough and impressive
> piece of work for such a short time period.
>
> Thank you for that. Viktor's paper did help me a lot while writing the
> code. I guess you
On Wed, Jun 17, 2020 at 7:22 PM Alexei Podtelezhnikov
wrote:
> Hi Anuj,
>
> Please let me finish my thoughts below...
>
> >> Each curved segment has a large number of neighboring grid points.
> >> each of which has a unique nearest projection on the curve. The curve
> >> is naturally sampled by
On Tue, Jun 16, 2020 at 9:54 PM Anuj Verma wrote:
>
> > Also I'm surprised that you haven't put the code get_min_distance code
> for each edge type into a function.
> > Would you prefer that I comment re these on github?
>
> I don't think that will be necessary. I will fix that while adding in
>
Hi David,
I've been meaning to reply to your request but the list of things I wanted
to communicate kept growing exponentially and so I have not been able to
say.
But here, from a technical perspective this is my biggest issue, which you
can also see as a roadmap:
SDFs, 1 unit in distance is one pixel. And Anuj,
> I'm not sure 2.14 is enough precision in the integer part. It's been a
> while, but I believe I got better results with at least 3 bits of integer.
>
> On Wed, Jun 3, 2020 at 6:33 PM Behdad Esfahbod wrote:
>
>> Jim,
>>
>
I want to raise same concerns that David did in a thread a few months ago.
I don't think a logging library is neither needed nor appropriate for
FreeType. Werner, can you please summarize why you think this is a good
idea?
--
behdad
http://behdad.org/
On Mon, Jun 8, 2020 at 9:53 AM Werner LEMBERG wrote:
>
> > I want to raise same concerns that David did in a thread a few
> > months ago.
> >
> > I don't think a logging library is neither needed nor appropriate
> > for FreeType. Werner, can you please summarize why you think this
> > is a good
had your chance to contribute Distance
>> Fields before May and will have it after September.
>>
>> Best regards,
>> Alexei
>>
>>
>>
>>
>> On Thu, Jun 4, 2020 at 12:39 PM Behdad Esfahbod
>> wrote:
>> >
>> >
will have it after September.
>
> Best regards,
> Alexei
>
>
>
>
> On Thu, Jun 4, 2020 at 12:39 PM Behdad Esfahbod wrote:
> >
> > Thanks Jim.
> >
> > A 2.14 representation when 1 unit = 1em is sufficient. If we are
> talking pixels then 10.6 or be
I find it a *very* bad idea to have code in FreeType that would write to a
file. Specially bad if that can be controlled by an env-var.
I still think what's desired can be done best by just revamping and writing
custom code in FreeType itself.
This is my last word on this particular topic, but
On Mon, Jun 1, 2020 at 3:10 PM Alexei Podtelezhnikov
wrote:
> On Mon, Jun 1, 2020 at 2:43 PM Werner LEMBERG wrote:
> > >> However there is an issue with the program, the glyphs which
> > >> contain intersecting contours have an issue. (example:
> > >> https://imgur.com/MxJfAwY)
> > >
> > > The
Anuj,
You cannot use just the orientation of the closest contour. That's what we
did in GLyphy but is wrong for reasons you found out. You need to
calculate actual winding number of the sampling point.
On Mon, Jun 1, 2020 at 3:21 AM Anuj Verma wrote:
> Hello Werner,
>
>
>
> *> As you like.
break the input curve on cusps if any. But
even that has not been an issue:
https://github.com/googlefonts/cu2qu/issues/6
Cheers,
behdad
On Wed, Jun 3, 2020 at 3:16 PM Behdad Esfahbod wrote:
> Hi Jim, others,
>
> Thanks for your input. I've been meaning to get into the discussion
Hi Jim, others,
Thanks for your input. I've been meaning to get into the discussion as
well but didn't get to.
I support your suggestions: generate from vector instead of bitmap, as well
as 8-bit 3.5 fixed point or similar at least as an option. In your 3.5
fixed-point, does one unit reflect
On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod wrote:
> On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov
> wrote:
>
>> >
>> > Wanted to point out that compiling with gcc and adding
>> "-stack-usage=2000" to get reports about stacks larger tha
What I said is wrong. But the blues array should be dynamically allocated,
and use a embedded version for small values. I'll work on it.
behdad
http://behdad.org/
On Mon, Sep 4, 2023 at 3:47 PM Behdad Esfahbod wrote:
> On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod wrote:
>
>> O
On Mon, Sep 4, 2023 at 8:27 PM Werner LEMBERG wrote:
>
> > Upon further investigation, I think my proposed change is correct.
>
> Thanks a lot, committed!
>
Thanks. One thing I don't understand, is the "+ 2" in the code below:
AF_LatinBlue blue_sorted[AF_BLUE_STRINGSET_MAX_LEN + 2];
Upon further investigation, I think my proposed change is correct.
behdad
http://behdad.org/
On Mon, Sep 4, 2023 at 4:26 PM Behdad Esfahbod wrote:
> What I said is wrong. But the blues array should be dynamically allocated,
> and use a embedded version for small values. I'l
On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov
wrote:
> >
> > Wanted to point out that compiling with gcc and adding
> "-stack-usage=2000" to get reports about stacks larger than 2000 bytes is
> probably the easiest way to track down large stacks at the moment. Note
> that
I don't think this (caching flatten outlines) is a good idea. Pretty much
all serious implementations cache the rendered image. And pretty much all
uses of FreeType don't render the entire glyph set. And must
implementations care a lot more about loading performance. I know you are
suggesting new
If you don't need to do this from C necessarily, check out ftCLI:
https://github.com/ftCLI/FoundryTools-CLI
Or "fonttools ttLib --help" from fonttools:
https://github.com/fonttools/fonttools
behdad
http://behdad.org/
On Mon, Oct 23, 2023 at 6:44 AM Francesco Pretto wrote:
> Hello,
>
>
Hi,
I'm debugging an issue where FT_Get_Advance(), even in its fast path
(NO_HINTING), seems to be much slower than the equivalent HarfBuzz code.
Much of it seems to be overhead because we have to call FT_Get_Advance()
one glyph at a time and it does multiple indirections before getting the
Hi Werner,
Any chance the one-line patch below can be applied?
Thanks,
behdad
http://behdad.org/
On Fri, May 20, 2022 at 11:05 AM Behdad Esfahbod wrote:
> Hi,
>
> I'm debugging an issue where FT_Get_Advance(), even in its fast path
> (NO_HINTING), seems to be much slower than th
Hi Werner,
Regarding this thread:
https://lists.nongnu.org/archive/html/freetype-devel/2022-05/msg4.html
I finally spent enough time on it to have a clue. I wrote up my findings in
a document:
https://docs.google.com/document/d/1wskYbA-czBt57oH9gEuGf3sWbTx7bfOiEIcDs36-heo
The short answer
Hi,
HarfBuzz now renders COLRv1, in two ways:
1. a native implementation,
2. using the FreeType API.
For the latter, we found a couple of issues that I like to report:
- In using FT_Get_Paint_Layers(), I found that I need to initialize the
out-parameter FT_OpaquePaint to zero, otherwise
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 current
Hi,
In benchmarking FreeType face loading, I noticed that the following two
loops take considerable time when loading CFF1 face:
--- a/src/cff/cffobjs.c
+++ b/src/cff/cffobjs.c
@@ -695,8 +695,8 @@
FT_TRACE4(( " %5d ", idx + 390 ));
- for ( l = 0; l < s1len; l++ )
-
Humm. I cannot reproduce this anymore. Will report if that changes.
behdad
http://behdad.org/
On Sun, Jul 30, 2023 at 12:41 PM Behdad Esfahbod wrote:
> Hi,
>
> In benchmarking FreeType face loading, I noticed that the following two
> loops take considerable time when loadi
On Tue, Dec 19, 2023 at 11:25 AM Alexei Podtelezhnikov
wrote:
>
> Note that freetype does not use the overlap flags to determine the path
> fill rule (winding vs even-odd), it always uses winding for TT or CFF2
> variable fonts, as the spec mandates; the discussion here is about freetype
> using
CFF was even-odd. CFF2 is non-zero winding.
behdad
http://behdad.org/
On Tue, Dec 19, 2023 at 9:50 AM Hin-Tak Leung
wrote:
> This is the same as the winding rule concept (overlap once = wounded
> twice) ... I seem to remember one of them is even-odd and the other is
> non-zero, and quite
On Tue, Dec 19, 2023 at 1:02 PM Skef Iterum wrote:
> CFF2 is released, has been for years. As far as I know there's no solid
> convention for ignoring unrecognized operators in a CharString, so this
> would be CFF2 minor 1 at best. Which would be years out in terms of
> support.
>
> Practically
Hi David,
As mentioned on the issue, the main thing I like to see you address is,
instead of walking all subtables, only walk subtables from 'kern' features.
behdad
On Tue, Jan 23, 2024 at 10:43 AM David Saltzman
wrote:
> it might be useful to add (also) either compile-time or runtime switch
There's no guarantee that the user's shell is sh-compatible. autoconf
really means sh here, because that's the shell the script is written for.
Just symlink your favorite shell to sh then, if it's compatible.
behdad
http://behdad.org/
On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi
wrote:
>
posibility, not the
> developer's. So no need to worry about that; the important thing is to give
> users the freedon to customize for their custom environments (as GNU
> Autoconf does for example; but Autoconf is not used in FreeType).
>
> Cheers,
> Mohammad
>
>
>
>
Scratch that.
Where is it exactly failing? On Unix, the build system is essentially
autoconf, so it should respect SHELL as you suggest.
behdad
http://behdad.org/
On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod wrote:
> Can you check if also setting CONFIG_SHELL helps?
>
> behd
ed, we don't keep it under version control).
>
> Cheers,
> Mohammad
>
> On 5/1/24 11:17 PM, Behdad Esfahbod wrote:
> > Scratch that.
> >
> > Where is it exactly failing? On Unix, the build system is essentially
> > autoconf, so it should respect SHELL as you su
is free to use
> any shell they want with any program's build.
>
> Cheers,
> Mohammad
>
>
>
>
> On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod
> wrote:
>
>> I'm not talking about the user overriding the shell specifically. I'm
>> talking about users w
401 - 479 of 479 matches
Mail list logo
