Re: [ft-devel] "Inside the fastest font renderer in the world"
I might take a look at it, but no guarantees about my availability. 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 would provide a C interface for compatibility. - Graham On 04/08/2016 20:42, Werner LEMBERG wrote: A first step towards making this new renderer generally useful would be to convert it or compile it (using the Crust compiler) to C. Is there a volunteer for this? Raph is quite busy, he told me... Werner -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
For the record, Rust can also produce object files with C interfaces. Firefox is currently using this: you can, optionally, replace the MP4 parser with a Rust version, and this is done in Mozilla's official builds. A caveat would be that Rust supports less platforms. Also, I think SIMD intrinsics and inline asm are still limited to nightly Rust. On Fri, Aug 5, 2016 at 9:42 AM Graham Asher wrote: > I might take a look at it, but no guarantees about my availability. 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 would provide a C interface for > compatibility. > > - Graham > > > > On 04/08/2016 20:42, Werner LEMBERG wrote: > > A first step towards making this new renderer generally useful would > be to convert it or compile it (using the Crust compiler) to C. > > > Is there a volunteer for this? Raph is quite busy, he told me... > > > Werner > > > -- > Graham Asher > founder and CTO > CartoType Ltd > graham.as...@cartotype.com > +44 (0) 7718 895191 > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
> 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 a C++ compiler (and probably never will). Given that everything in FreeType is C, it would be a severe complication if just a single file becomes C++. In other words, I would have to convert your C++ code in C, which means double work... As an alternative, there is https://github.com/uwplse/crust a Rust-to-C compiler – has anyone tried this? I don't know whether it produces code which runs as fast as the Rust equivalent. If this works reliably, I could imagine to have both a Rust source file and its translation in the FreeType git repository. Unfortunately, `crust' needs a huuuge set of preliminaries... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
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 lack of support for 32-bit integers; and I doubt very much whether they would have any need to rasterize glyphs. There's an interesting discussion here (http://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems) which gives both sides of the issue, but which contains many errors and irrelevancies... however, I respect your point of view and won't tread a well-worn path again. Best regards, Graham On 05/08/2016 09:00, Werner LEMBERG wrote: 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 a C++ compiler (and probably never will). Given that everything in FreeType is C, it would be a severe complication if just a single file becomes C++. In other words, I would have to convert your C++ code in C, which means double work... As an alternative, there is https://github.com/uwplse/crust a Rust-to-C compiler – has anyone tried this? I don't know whether it produces code which runs as fast as the Rust equivalent. If this works reliably, I could imagine to have both a Rust source file and its translation in the FreeType git repository. Unfortunately, `crust' needs a huuuge set of preliminaries... Werner -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
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 to run FreeType in any case because of lack of support for 32-bit integers; and I doubt very much whether they would have any need to rasterize glyphs. Speaking for Ghostscript, this is not the case. We are required to support a number of embedded operating systems, many of which are of some degree of legacy and which have limited (if any) support for C++. These platforms drive printers, which very much do have a need to render glyphs :-) Please don't assume that all glyph rendering is for screen display! I no longer have responsibility for FreeType in Ghostscript, but if FT were to move to requiring C++ I think we would have to fork it (as we did once before) in order to maintain a pure C build. Personally, as one of the two people who did a load of work to get FreeType integrated into Ghostscript in place of the (old) fork that was being used, I'd be very disappointed to have to go back to using a fork. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
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 availability. 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 would provide a C interface for compatibility. > > - Graham > > >> On 04/08/2016 20:42, Werner LEMBERG wrote: >>> A first step towards making this new renderer generally useful would >>> be to convert it or compile it (using the Crust compiler) to C. >> Is there a volunteer for this? Raph is quite busy, he told me... >> >> >> Werner > > -- > Graham Asher > founder and CTO > CartoType Ltd > graham.as...@cartotype.com > +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype-devel Digest, Vol 139, Issue 6
> Date: Fri, 05 Aug 2016 09:24:26 +0100 > From: Graham Asher To: Ken Sharp Cc: Werner LEMBERG , freetype-devel@nongnu.org, madig...@gmail.com Subject: Re: [ft-devel] "Inside the fastest font renderer in the world" > 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 Really? I assume that Ken was referring to Chris Liddell being the other one. Apologies if this sound like I am ignorant of it... ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint: broken components when ARGS_ARE_XY_VALUES is false
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 instead of all the time. For example, when Molengo-Reular.ttf (from https://github.com/moyogo/molengo-fonts/releases/download/v0.10/Molengo-fonts-0.10.tar.gz) goes through ttfautohint --composites, the composite glyphs are broken. The gravecomb glyph does not have any point index changes. However it is used as a component in Agrave, while ttfautohint correctly increments the first matched point, i.e. the point index to match on the whole composite Agrave, it also incorrectly increments the second matched point index (arg2), i.e. the point index being matched on gravecomb. The first point needs to be incremented since a '.ttfautohint' component with one point is added as the first component. But the second point should not since no point index where changed in gravecomb. Cheers, ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
