Re: FT_Add_Module() and related functions

2020-06-11 Thread Werner LEMBERG


> I don't think we want to statically link any SVG renderer to the
> library by default.  There are so many subtleties related to vector
> graphics rendering, that there is no "good" default choice to make.
> In other words, any default we select at link time would probably be
> inappropriate for a lot of developers anyway.

I agree.  However, I want to have a default SVG rendering engine
detected automatically at configure time, and which can be easily
overridden by a configure option.  Ideally, this is default is SVG
Native 

  https://github.com/adobe/svg-native-viewer

Unfortunately, development seems to be stalled; we probably have to go
for something else.  Moazin right now is doing another GSoC project;
according to an e-mail exchange with him he plans to work again on the
SVG stuff after GSoC will have finished.


   Werner



Re: [Freetype-devel] Re: GSOC - Distance Fields

2020-06-11 Thread Anuj Verma
Hello All,

A progress update. I have ported the entire program to fixed point
and it looks good to me. It's still not perfect and there are places
where overflow can happen ( specifically in function `solve_cubic_equation'
),
so currently I'm working on fixing those.
As usual you can check it out here (
https://github.com/preversewharf45/freetype2-sdf/tree/FT_Fixed )
and the demo here ( https://github.com/preversewharf45/freetype2-sdf-demo )

Anuj


Re: FT_Add_Module() and related functions

2020-06-11 Thread David Turner
Hello everyone,

Le mar. 9 juin 2020 à 14:14, Alexei Podtelezhnikov  a
écrit :

> Hi David,
>
> I actually thought about FT_Add_Module as a visionary interface for
> dynamically plugging alternative renderers:
>
> https://github.com/raphlinus/font-rs
> https://github.com/mooman219/fontdue
> https://github.com/servo/pathfinder
>
> Admittedly, none of those projects explored this possibility or there
> are more straightforward ways to achieve this.
>
>
I'm not against the idea of being able to plug external renderers to
FreeType if it makes sense. The OT-SVG case is a compelling reason to.
However, I want to deprecate the existing module API. It has grown a little
too complex for its own good, and there are opportunities to simplify the
codebase (making the code both shorter and more maintainable), by getting
rid of the ability to add/replace/remove arbitrary modules.

That would not prevent us from introducing a new way to "plug" renderers,
probably with a new interface, that would be much more specific, and would
deal better with subtle issues like deallocating bitmap buffers that were
allocated by the renderer.

In the case of OT-SVG, I haven't looked at the problem in detail, but it
looks like this would require a new glyph image type to support (doable),
and the ability to provide FreeType with an interface it could use to
render these with a third-party library.
Do you know if the format allows compositing SVG and non-SVG glyphs
together? That would be ... difficult to support though.

I don't think we want to statically link any SVG renderer to the library by
default. There are so many subtleties related to vector graphics rendering,
that there is no "good" default choice to make. In other words, any default
we select at link time would probably be inappropriate for a lot of
developers anyway.

- David

Then there is this whole discussion on how to integrate SVG, which
> again comes down to using an alternative renderer module and whether
> it is worth hooking inside a single module or Add/Remove multiple
> modules.
> https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00058.html
>
> So I know that nobody uses FT_Add_Module but it is not a bad interface.
>
> Alexei
>


Re: [freetype2] Remove #include FT_XXX_H includes from library sources

2020-06-11 Thread Werner LEMBERG


> And here's the patch to fix freetype2-demos compilation first.

Applied too, thanks.


Werner



Re: [freetype2] Remove #include FT_XXX_H includes from library sources

2020-06-11 Thread Werner LEMBERG


> Thanks Werner, the patch looks good to me :-)

OK, applied.


Werner