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
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
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
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
>
>
>
>
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:
>
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
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
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
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,
>
>
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
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
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 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
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
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
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,
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
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 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,
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
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
>
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:
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
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
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
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
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
>
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 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
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
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
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
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 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,
. 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
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
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 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
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/
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
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,
>>
>
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
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
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
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
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
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
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
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
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
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,
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
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
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
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?
>
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
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
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
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
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
Note that OT-SVG only allows gzip-wrapper compressed documents, not
zlib-wrapped.
On Sat, Jun 8, 2019 at 1:57 AM Moazin Khatri wrote:
> Hi,
>
> In OpenType fonts, SVG documents can be either in plain text or gzip
> encoded.
>
> While writing the code to read these documents I looked for a
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 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
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 9:42 AM Werner LEMBERG wrote:
>
> >> Could you tell me more about "all the current energye is going in
> >> the wrong direction"? Do you think "spending much energy for the
> >> discussion which is not so much important"? Or, do you think
> >> "trying to implement
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
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 Wed, May 8, 2019 at 10:19 PM Werner LEMBERG wrote:
>
> >> 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.
>
> It's not moot at all IMHO. I want to have a default that
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
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 Thu, Apr 4, 2019, 12:40 AM Werner LEMBERG wrote:
>
> Hello Behdad!
>
>
> > When trying to download this:
> >
> > http://download.savannah.gnu.org/freetype/freetype-2.9.tar.bz2
> >
> > which is linked from:
> >
> > http://download.savannah.gnu.org/releases/freetype/
>
> Is it?
It was
When trying to download this:
http://download.savannah.gnu.org/freetype/freetype-2.9.tar.bz2
which is linked from:
http://download.savannah.gnu.org/releases/freetype/
I get a 404. Our HarfBuzz CI bots are hitting this. Any idea?
--
behdad
http://behdad.org/
Skia has been rendering color fonts to billions of devices for over five
years now, based on existing FreeType. Patches existed for cairo for the
same time and were finally integrated last year. This idea that something
big in FreeType has happened re color recently sounds detached from reality
On Tue, Feb 19, 2019 at 2:27 AM Werner LEMBERG wrote:
>
> > We're a group of researchers from University of California
> > Riverside. We recently discovered that the outline processing (font
> > translation/decomposition) subroutine in the Freetype version 2.9.1
> > takes variable amount of time
Fully agree. Thanks Nikolaus and Ben.
On Mon, Feb 4, 2019, 3:06 PM Ben Wagner wrote:
> So, to summarize, the new behavior is sTypo (if UseTypoMetrics), then hhea
> (if not 0), then sTypo (if not 0), then usWin. This is now consistent
> across all fonts; variable fonts do not have a different
.png
> https://i.postimg.cc/PJjQhWrT/Bildschirmfoto-vom-2019-01-31-00-09-56.png
>
> Text becomes compressed.
> Am Do, 31. Jan, 2019 um 12:38 A. M. schrieb Behdad Esfahbod
> :
> > That's what line-gap is: gap between consecutive lines. There is no
> > line before the first line, an
That's what line-gap is: gap between consecutive lines. There is no line
before the first line, and as such, no gap.
On Wed, Jan 30, 2019 at 4:37 PM Nikolaus Waxweiler
wrote:
> Even more testing.
>
> ftview and Qt actually do the same GTK does: they don't add the line
> gap to the top, so text
On Tue, Jan 22, 2019 at 11:47 AM Werner LEMBERG wrote:
>
> Of course. Only if some preprocessor macros are defined at configure
> time, this feature is available – I won't change that. In other
> words, it will stay as a developer-only feature.
Right. Which makes using en external library
Werner,
Please don't use an external library. Logging in FreeType is for
developers only, and some parts maybe for font designers. Clients who just
want to render text don't need the logging capabilities. Just keep it
simple.
On Mon, Jan 21, 2019 at 4:35 PM Yash Khasbage
wrote:
> Hi
> I
On Sat, Dec 22, 2018 at 11:23 AM Nikolaus Waxweiler
wrote:
>
> > The thinking within the working group was that no one uses win
> > metrics, so we didn't encode their variations. Indeed, the only time
> > one uses them these days is if typo and hhea metrics are not set...
>
> >
> But MVAR tags
On Sat, Dec 22, 2018 at 8:43 AM Nikolaus Waxweiler
wrote:
> > There's also the question of whether MVAR tags should apply to
> > whatever was used for ascent/descent. I think yes. And I'll
> > implement that in HB.
>
> What would you do when
>
> 1. the typo metrics are modified by the MVAR
On Thu, Dec 20, 2018 at 5:32 AM Werner LEMBERG wrote:
>
> > I just tested the static and variable fonts in macOS 10.14 TextEdit.
> > For the static instances, it presumably takes the hhea metrics, for
> > the VF, it always takes typo metrics. (It also adds the line gap at
> > the bottom, making
On Thu, Dec 20, 2018 at 6:02 AM Nikolaus Waxweiler
wrote:
> > This is certainly the most convenient solution for me since I have
> > nothing to do on the FreeType side :-)
>
> (As an aside, GTK/Pango seem to make the same mistake as TextEdit then,
> putting the line gap at the bottom instead of
On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov
wrote:
> On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov
> wrote:
> > > Alexei, I think we miscommunicate.
> >
> > I struggle to get your attention to FT_Glyph_To_Bitmap.
>
> I just discovered that, while ignoring the FT_Glyph
On Tue, Dec 18, 2018 at 5:35 AM Werner LEMBERG wrote:
>
> >> FreeType is about to make a major leap into color rendering.
> >
> > Is it? Color rendering was the news before variable-fonts were
> > news. So 2013. The world has moved on.
>
> You completely misunderstood. Alexei talks about
On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov
wrote:
> FT_Render_Glyph used to be democratic. The renderers were chosen based
> on the match between the glyph format and the rendering mode. The only
> way to keep it this way is either FT_RENDER_MODE_BGRA or
> FT_GLYPH_FORMAT_LAYERED.
On Tue, Dec 18, 2018 at 11:43 AM Nikolaus Waxweiler
wrote:
> Thanks Alexei for chiming in at
> https://github.com/googlei18n/fontmake/issues/492#issuecomment-448249543.
>
> > The following seems to be different: hhea does not seem to be used in
> VF. Compare and decide which one is correct.
> >
On Sat, Dec 15, 2018 at 11:10 PM Alexei Podtelezhnikov
wrote:
>
> FreeType is about to make a major leap into color rendering.
Is it? Color rendering was the news before variable-fonts were news. So
2013. The world has moved on.
> It is
> possible to make it right while keeping rendering
1 - 100 of 479 matches
Mail list logo
