[ft-devel] ttfautohint: broken components when ARGS_ARE_XY_VALUES is false

2016-08-05 Thread Denis Jacquerye
Hi, When composite glyphs have components with ARGS_ARE_XY_VALUES false, i.e. arg1 and arg2 are matched point indeces, `ttfautohint --composites` incorrectly increments the second matched point index. It should only change the second matched point if the component glyph has changed point indeces

Re: [ft-devel] "Inside the fastest font renderer in the world"

2016-08-05 Thread Alexei Podtelezhnikov
There is an API to use whatever rasterizer you please with the rest of the Freetype https://www.freetype.org/freetype2/docs/reference/ft2-raster.html > On Aug 5, 2016, at 03:42, Graham Asher wrote: > > I might take a look at it, but no guarantees about my

Re: [ft-devel] "Inside the fastest font renderer in the world"

2016-08-05 Thread Graham Asher
I'd forgotten about that! I was the other person. On 05/08/2016 09:21, Ken Sharp wrote: Personally, as one of the two people who did a load of work to get FreeType integrated into Ghostscript -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191

Re: [ft-devel] "Inside the fastest font renderer in the world"

2016-08-05 Thread Ken Sharp
At 09:09 05/08/2016 +0100, Graham Asher wrote: I see your point, but I think that adding obfuscation (the extra complexity introduced by using C) to the code to support a tiny and vanishing minority of systems without C++ is not worth the bother; such systems would very probably not be able

Re: [ft-devel] "Inside the fastest font renderer in the world"

2016-08-05 Thread Graham Asher
Werner, I see your point, but I think that adding obfuscation (the extra complexity introduced by using C) to the code to support a tiny and vanishing minority of systems without C++ is not worth the bother; such systems would very probably not be able to run FreeType in any case because of

Re: [ft-devel] "Inside the fastest font renderer in the world"

2016-08-05 Thread Werner LEMBERG
> I might take a look at it, but no guarantees about my availability. Thanks for the offer anyway :-) > I would convert it into C++, not C; C++ is a better fit, and there > is really no point in using C these days. I disagree. As far as I know, there are still embedded systems that don't have