>
> > I was trying to write some good error handling code in the
> > `librsvg' rendering port.
>
> If you say `rendering port', you mean code that gets added to librsvg,
> to FreeType, or to the calling application?
>

I mean the hook functions which the client will write and set
them using `FT_Property_Set'. These will of course be different for
each library. Have a look here:
https://bitbucket.org/moazin/librsvg-port-freetype-otsvg/src/master/port/rsvg_port.c
and search `FT_THROW' in that file.


> > This worked well but I just realized that `FT_Throw' is something
> > internal to FreeType just like `FT_NEW' and can't be used from
> > outside.  As long as FreeType is being linked statically, it works
> > great, otherwise I get an undefined reference error.
>
> So this sounds as if the code is not part of FreeType...
>

Yes, the thing is, the default hooks are a part of FreeType since they
are part of FreeType's build process. But any external hooks are not.
We have to make sure both the default and external hooks work in
exactly the same way. :)


> I'm not sure whether it makes sense to define error codes for external
> stuff that is not directly used by FreeType.  Maybe you just return
> values like -1 or -2 as error codes?
>

Yes, I am sure that there are at most 3 types of errors returned by the
hooks. So I could create my own mapping, say:
0 => everything good
-1 => out of memory error
-2 => invalid outline
-3 => invalid svg doc
-4 => id not found in document
And `ft_svg_render' can do FT_THROW depending on which one
it is. This can be one solution. These checks will be written on
line 97 in `ftsvg.c':
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/svg/ftsvg.c?h=GSoC-2019-moazin#n97
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Reply via email to