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

[Alexei Podtelezhnikov]

On Fri, Jun 12, 2020 at 12:31 AM Anuj Verma  wrote:
> ... specifically in function `solve_cubic_equation' ...

How many times do you have to solve this for each glyph? How many
different solutions (aka curve points) do you have to find for each
curved segment? I figure there are a lot of grid-curve pairs to
enumerate with most of the curve segment sampled fairly frequently...

Do you see where I am going?

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,
I have updated the progress report for this week @ here


Thanks,
Priyesh

On Sat, Jun 6, 2020 at 8:34 PM Werner LEMBERG  wrote:

>
> > The gnulib repository provides a module 'unistd' for creating a
> > 'unistd.h' header file; this works on Windows too.
> >
> >   https://www.gnu.org/software/gnulib/
>
> By the way, the gnulib repository also provides an interface to
> threads – including Windows.  If you install the corresponding modules
> you automatically get a configure option
>
>   --enable-threads={posix,windows,isoc}
>
> (with MSVC and mingw support for 'windows').  The very recent commit
> 10cf67b5e333 in the gnulib repository describes the available modules
> and options for multithreading.
>
> Note that my knowledge of thread programming is zero, so please handle
> my observations with some care.
>
> Of course, it is problematic for FreeType license-wise to rely on
> gnulib since the latter uses the LGPLv2+ license.  On the other hand,
> linking with a logging library would be mainly used for debugging
> purposes and not for end products, so a dependency on LGPLv2+ might be
> OK if the corresponding code is properly guarded with preprecessor
> conditionals (which is a good idea anyway).
>
>
> Werner
>

Re: FT_Add_Module() and related functions

[Vincent Torri]

On Fri, Jun 12, 2020 at 3:23 PM Alexei Podtelezhnikov
 wrote:
>
> On Fri, Jun 12, 2020 at 7:22 AM Vincent Torri  wrote:
> >
> > On Fri, Jun 12, 2020 at 12:47 PM Alexei Podtelezhnikov
> >  wrote:
> > >
> > > On Fri, Jun 12, 2020 at 5:05 AM Moazin Khatri  
> > > wrote:
> > > >>
> >
> > > Almost certainly, they use FT_Outline_Render with the callback
> > > params.gray_spans doing all kinds of crazy color gradients.
> >
> > https://git.enlightenment.org/core/efl.git/tree/src/lib/ector/software/ector_software_rasterizer.c
>
> The first three functions in this file are exactly the type of
> FT_SpanFunc

they are all prefixed with SW_ because we also have a opengl rasterizer

>then you call:
> sw_ft_grays_raster.raster_render(thread->raster, );
> Do you  by any chance use FT_Get_Module to set up sw_ft_grays_raster?

git grep tells me that it is not used, but as I have said, i've never
touched this part

Vincent Torri

Re: FT_Add_Module() and related functions

[Alexei Podtelezhnikov]

On Fri, Jun 12, 2020 at 7:22 AM Vincent Torri  wrote:
>
> On Fri, Jun 12, 2020 at 12:47 PM Alexei Podtelezhnikov
>  wrote:
> >
> > On Fri, Jun 12, 2020 at 5:05 AM Moazin Khatri  
> > wrote:
> > >>
>
> > Almost certainly, they use FT_Outline_Render with the callback
> > params.gray_spans doing all kinds of crazy color gradients.
>
> https://git.enlightenment.org/core/efl.git/tree/src/lib/ector/software/ector_software_rasterizer.c

The first three functions in this file are exactly the type of
FT_SpanFunc then you call:
sw_ft_grays_raster.raster_render(thread->raster, );
Do you  by any chance use FT_Get_Module to set up sw_ft_grays_raster?

intel compiler support interest?

[Stephen McDowell]

Hi :)

I help maintain the spack package manager when I can, currently users with
intel compilers cannot build / install any version after 2.7.1 due to the
usage of __builtin_shuffle (for some reason Intel still doesn't support
this).

https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sfnt/pngshim.c#n64

As far as I can tell, the easiest thing to do is to just disable the
vectorized code (see patch below).  I do not experience any compilation
problems, but was unable to determine how to test this code.  I could only
find the fuzzer on GitHub and it wasn't clear to me which executable would
even test this :/

Would the freetype team intend on accepting this patch?  I will be creating
a slightly different one for spack (minimal diff just changing 2 lines),
but I took the liberty of re-lining up the operators since it looks like
that's what was once going on here :)

diff --git a/src/sfnt/pngshim.c b/src/sfnt/pngshim.c
index 3acc1d551..ff40eab66 100644
--- a/src/sfnt/pngshim.c
+++ b/src/sfnt/pngshim.c
@@ -61,11 +61,13 @@
 /* predates clang; the `__BYTE_ORDER__' preprocessor symbol was */
 /* introduced in gcc 4.6 and clang 3.2, respectively.   */
 /* `__builtin_shuffle' for gcc was introduced in gcc 4.7.0. */
-#if ( ( defined( __GNUC__ )&& \
-( ( __GNUC__ >= 5 )  ||   \
-( ( __GNUC__ == 4 ) && ( __GNUC_MINOR__ >= 7 ) ) ) ) ||   \
-  ( defined( __clang__ )   && \
-( ( __clang_major__ >= 4 )   ||   \
+/* Intel compilers do not currently support __builtin_shuffle.  */
+#if !defined(__INTEL_COMPILER) /* NOTE: Intel check must be first.  */ && \
+( ( defined( __GNUC__ )&& \
+( ( __GNUC__ >= 5 )|| \
+( ( __GNUC__ == 4 ) && ( __GNUC_MINOR__ >= 7 ) ) ) )   || \
+  ( defined( __clang__ )   && \
+( ( __clang_major__ >= 4 ) || \
 ( ( __clang_major__ == 3 ) && ( __clang_minor__ >= 2 ) ) ) ) ) && \
 defined( __OPTIMIZE__ )&& \
 defined( __SSE__ ) && \

Please let me know what you think / if there are any changes you would
like.  Thanks for freetype!

-Stephen McDowell

Re: FT_Add_Module() and related functions

[Vincent Torri]

On Fri, Jun 12, 2020 at 12:47 PM Alexei Podtelezhnikov
 wrote:
>
> On Fri, Jun 12, 2020 at 5:05 AM Moazin Khatri  wrote:
> >>

> Almost certainly, they use FT_Outline_Render with the callback
> params.gray_spans doing all kinds of crazy color gradients.

this function is not used. According to git, they use the glyph stroker API

the freetype code is used here :
https://git.enlightenment.org/core/efl.git/tree/src/lib/ector/software/ector_software_rasterizer.c
and is prefixed with SW_ (for software, as opposed to gl code that we
have too)

Vincent Torri

Re: FT_Add_Module() and related functions

[Alexei Podtelezhnikov]

On Fri, Jun 12, 2020 at 5:05 AM Moazin Khatri  wrote:
>>
>> > 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.
>>
>> for what it worth, in our project, we use freetype engine to render svg
>
>
> If it's okay, could you describe how you do this? SVGs are complex and I'd be 
> interested in knowing how you render them with FreeType.

Almost certainly, they use FT_Outline_Render with the callback
params.gray_spans doing all kinds of crazy color gradients.

Re: FT_Add_Module() and related functions

[Moazin Khatri]

>
> > 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.
>
> for what it worth, in our project, we use freetype engine to render svg
>

If it's okay, could you describe how you do this? SVGs are complex and I'd
be interested in knowing how you render them with FreeType.

Re: FT_Add_Module() and related functions

[Moazin Khatri]

Hello David,

I am a final year student of Engineering from Pakistan. It was my GSoC 2019
project to add OTSVG support to FreeType.

The final project report is available at:
https://moazin.bitbucket.io/gsoc-2019/ in case you want to read it. It has
all the details of how the project was accomplished. If you have any
questions or feedback please let me know. :-)

The code wasn't merged because we were blocking on a functionality needed
from the svg-native-viewer library that can give a bounding box of an SVG
document. Unfortunately, I couldn't find the time to contribute it myself
and at the moment I am busy with my GSoC 2020 project with Inkscape.


> 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.
>

Yes, the hooks do this.


> 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.
>

Yes, FT_GLYPH_FORMAT_SVG and FT_SvgGlyph.


> Do you know if the format allows compositing SVG and non-SVG glyphs
> together? That would be ... difficult to support though.
>

Umm, not sure, but if I recall correctly no such thing is mentioned in the
ot-svg specs. And why would someone want to render both glyphs together (if
that's what compositing means)?


> 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.
>

Hmm, this is one of the most heavily debated matter of the project. :-D

Re: FT_Add_Module() and related functions

[Vincent Torri]

On Fri, Jun 12, 2020 at 7:07 AM Werner LEMBERG  wrote:
>
>
> > 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.

for what it worth, in our project, we use freetype engine to render svg

regards

Vincent  Torri