> Another major issue that I have with the code is that it is very
> error-prone and very cumbersome to have these 1000 macros for
> declaring and defining classes. I would really prefer if we could
> use a simpler scheme that, gasps, relies on the C pre-processor, but
> at least would make our li
Thanks you werner, I did read the second set of patches, and my comments
still stand.
Another major issue that I have with the code is that it is very error-prone
and very cumbersome
to have these 1000 macros for declaring and defining classes. I would really
prefer if we could
use a simpler schem
> It would be nicer if you could keep the convention instead of
> prepending an extra FT_Library parameter at the start of the
> function. Indeed, you should instead store the FT_Library handle
> into the CFF_Parser object and pass it to cff_parser_init, then
> re-use it in subsequent functions.
> Can you add some clarification to the ChangeLog of the first patch
> that explain why it is needed ?
>
> Regarding the second patch, [...]
David, these two patches are superseded by the suite of patches in
http://lists.gnu.org/archive/html/freetype-devel/2009-03/msg00095.html
Please comme
Hello,
thanks a lot for your work. Can you add some clarification to the ChangeLog
of the first patch that explain why it is needed ?
Regarding the second patch, the internal code uses the convention of naming
functions as:
object_method( Object* o, )
It would be nicer if you could keep t
