Hello
We are creating a edge effect (Depressed) on a Pixmap buffer using freetype
library.we are facing the below issue
When loading a freetype font, it comes with a bounding-box. We are trying
to create depressed edge effect by writing the font multiple times in (x-i)
and (y-i) positions to
On Wed, Jun 3, 2020 at 6:11 AM Niyas k wrote:
> When loading a freetype font, it comes with a bounding-box. We are trying to
> create depressed edge effect by writing the font multiple times in (x-i) and
> (y-i) positions to create the depressed edge effect. Now with the
> bounding-box in
Forgive me for coming into this late -- a colleague pointed me to this
thread a couple of days ago and I'm just catching up. I work on Skia, and
we've been generating SDFs from glyphs for quite some time now, so the
possibility of just getting them from Freetype is pretty exciting.
I hope you
> lol. Intersecting contours have been a reality of TrueType since forever.
> The cedilla on a c always overlapped it. That's why there's a fill rule...
>
lol? Two straight lines intersect inside a square pixel. What's the
coverage? Please come back with a formula when you have it. Stop
*> The only remaining question is how to represent the final output data.*
* > 8bit? 16bit?*
I am thinking of using 16bit 2.14 to represent the final output data.
Then the external application can convert the data however it wants.
Anuj
> > I think we do want a 8bit representation at least, and possible a
> > higher one.
>
> Currently I am using 32bit floats, but since freetype doesn't use
> floats I am thinking of using 32bit 16.16 fixed point instead.
I think this is the right choice for intermediate computations.
Alexei
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.
Jim,
I see that in your implementation you are converting cubics to quadratic
spline. That makes a lot of sense and I support that. For the conversion
though, I see a messy piece of code, which is typical of that kind
of thing. I like to introduce you to cu2qu algorithm which we designed and
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 Wed, Jun 3, 2020 at 10:48 PM Anuj Verma wrote:
>
> Hello Behdad, Jim,
>
> > I see that in your implementation you are converting cubics to quadratic
> > spline. That makes a lot of sense and I support that.
>
> Is it better to split the cubic bezier into quadratic one? why? Currently I
> am
Hello Behdad, Jim,
*> I see that in your implementation you are converting cubics to quadratic
spline. That makes a lot of sense and I support that.*
Is it better to split the cubic bezier into quadratic one? why? Currently I
am using Newton-Raphson's iteration to find the
closest point on cubic
Hello Alexei,
*> Is 1/65563 not enough accuracy for you? Do not be greedy. What would >
you gain from extra accuracy in the world of discrete pixels?*
1/65563 is quite enough for SDF, my point is that in a 16.16 fixed point
I will only be using 18bits ( 1 for sign, 1 for integer and 16 for
On Wed, Jun 3, 2020 at 11:48 PM Anuj Verma wrote:
>
> Hello Alexei,
>
> > Is 1/65563 not enough accuracy for you? Do not be greedy. What would
> > you gain from extra accuracy in the world of discrete pixels?
>
> 1/65563 is quite enough for SDF, my point is that in a 16.16 fixed point
> I will
And here's the patch to fix freetype2-demos compilation first.
Le jeu. 4 juin 2020 à 02:42, David Turner a écrit :
> Since nobody does development on DOS or Windows 9x anymore, we can finally
> drop the requirement to use file names limited to the 8.3 format, which was
> the reason why the
15 matches
Mail list logo
