Re: [ft-devel] Regression issue - CFF
I will check which changeset relates this difference. Ivan Nincic wrote: Hello Werner, FYI: I run into a regression issue with the latest FT (trunk) version. Attached is a sample font. I don't claim that this is a valid font however FT was able to render the file in 2.4.4 but not in 2.4.9. IvanN ___ 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] Amalgamation: Aftermath.
On Apr 13, 2012, at 5:41 AM, Alan Coopersmith wrote: On 04/13/12 07:30 AM, Vinnie wrote: From: http://rawmaterialsoftware.com/viewtopic.php?f=6t=8654 those amalgamations are pretty convenient imo, i don't get why you got so much hostility on the freetype dev list A pretty convenient way to make your software full of security holes and other bugs if you don't spend the time to update it for every upstream patch, at which point you'll find that it's not all that convenient compared to just using a shared library. http://www.dwheeler.com/blog/2012/04/03/#insecure-libraries Amalgamation can be a way to make updating more convenient, thereby increasing security. This is true for projects that include Freetype source files directly rather than building a separate library and linking with it. Replacing old versions of freetype.c and freetype.h with newer versions of those same two files is far more convenient than replacing an old set of Freetype source files with a newer set, especially if files are renamed, removed, or added between versions. Here's the difference I'm talking about in one of our makefiles; instead of this: vpath ../freetype/src/autohint ../freetype/src/bdf ../freetype/src/cff ../freetype/src/cache \ ../freetype/src/gzip ../freetype/src/base ../freetype/src/pcf ../freetype/src/pfr \ ../freetype/src/psaux ../freetype/src/pshinter ../freetype/src/psnames ../freetype/src/raster \ ../freetype/src/sfnt ../freetype/src/smooth ../freetype/src/truetype ../freetype/src/type1 \ ../freetype/src/cid ../freetype/src/type42 ../freetype/src/winfonts ../freetype/src/lzw ../freetype/src/autofit \ ... OBJS_FREETYPE = \ bdf.o cff.o ftbase.o ftcache.o ftglyph.o ftgzip.o ftinit.o \ ftsystem.o pcf.o pfr.o psaux.o pshinter.o psnames.o raster.o \ sfnt.o smooth.o truetype.o type1.o type1cid.o type42.o winfnt.o fttype1.o \ ftbitmap.o ftlzw.o autofit.o We can have this: vpath ../freetype \ ... OBJS_FREETYPE = freetype.o We have a bunch of makefiles in which the amalgamation enables us to make that simplification. For some platforms we don't have makefiles, we have project files (such as for Xcode on Mac OS), and then the amalgamation is even more valuable, since it saves us from having to use a tedious graphical interface to add or remove source files when updating Freetype. My only concern about the amalgamated version of Freetype is that I don't know if it will continue to be maintained. For that reason, we haven't yet switched over to using the amalgamated version except experimentally. Currently, if I'm not mistaken, the amalgamation tool itself is not cross-platform. I haven't tried running it to produce the amalgamation myself. I've only tried using versions of freetype.c and freetype.h that Vinnie has made available. I would love to see the amalgamation tool become cross-platform and part of the Freetype project itself. Best wishes, Tom 文林 Wenlin Institute, Inc.Software for Learning Chinese E-mail: wen...@wenlin.com Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Aftermath.
I guess the preference using shared library for security issue is because the upgrading of single shared library can fix the security holes of various softwares depending the library by single action. I can upgrade MY software quickly is not valid objection to the preference. The valid objection should say I can update ALL softwares in my computer quickly, and, sometimes it should say I can update ALL softwares in quickly, even if I don't have the source SDKs of them. Anyway, such discussion is out of the scope of the people saying i don't get why I feel as some people asking for a bread (or fermented paste) in the miller's market. Regards, mpsuzuki Tom Bishop, Wenlin Institute wrote: On Apr 13, 2012, at 5:41 AM, Alan Coopersmith wrote: On 04/13/12 07:30 AM, Vinnie wrote: From: http://rawmaterialsoftware.com/viewtopic.php?f=6t=8654 those amalgamations are pretty convenient imo, i don't get why you got so much hostility on the freetype dev list A pretty convenient way to make your software full of security holes and other bugs if you don't spend the time to update it for every upstream patch, at which point you'll find that it's not all that convenient compared to just using a shared library. http://www.dwheeler.com/blog/2012/04/03/#insecure-libraries Amalgamation can be a way to make updating more convenient, thereby increasing security. This is true for projects that include Freetype source files directly rather than building a separate library and linking with it. Replacing old versions of freetype.c and freetype.h with newer versions of those same two files is far more convenient than replacing an old set of Freetype source files with a newer set, especially if files are renamed, removed, or added between versions. Here's the difference I'm talking about in one of our makefiles; instead of this: vpath ../freetype/src/autohint ../freetype/src/bdf ../freetype/src/cff ../freetype/src/cache \ ../freetype/src/gzip ../freetype/src/base ../freetype/src/pcf ../freetype/src/pfr \ ../freetype/src/psaux ../freetype/src/pshinter ../freetype/src/psnames ../freetype/src/raster \ ../freetype/src/sfnt ../freetype/src/smooth ../freetype/src/truetype ../freetype/src/type1 \ ../freetype/src/cid ../freetype/src/type42 ../freetype/src/winfonts ../freetype/src/lzw ../freetype/src/autofit \ ... OBJS_FREETYPE = \ bdf.o cff.o ftbase.o ftcache.o ftglyph.o ftgzip.o ftinit.o \ ftsystem.o pcf.o pfr.o psaux.o pshinter.o psnames.o raster.o \ sfnt.o smooth.o truetype.o type1.o type1cid.o type42.o winfnt.o fttype1.o \ ftbitmap.o ftlzw.o autofit.o We can have this: vpath ../freetype \ ... OBJS_FREETYPE = freetype.o We have a bunch of makefiles in which the amalgamation enables us to make that simplification. For some platforms we don't have makefiles, we have project files (such as for Xcode on Mac OS), and then the amalgamation is even more valuable, since it saves us from having to use a tedious graphical interface to add or remove source files when updating Freetype. My only concern about the amalgamated version of Freetype is that I don't know if it will continue to be maintained. For that reason, we haven't yet switched over to using the amalgamated version except experimentally. Currently, if I'm not mistaken, the amalgamation tool itself is not cross-platform. I haven't tried running it to produce the amalgamation myself. I've only tried using versions of freetype.c and freetype.h that Vinnie has made available. I would love to see the amalgamation tool become cross-platform and part of the Freetype project itself. Best wishes, Tom 文林 Wenlin Institute, Inc.Software for Learning Chinese E-mail: wen...@wenlin.com Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ ___ 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] Regression issue - CFF
Ah, I slipped to check what is the standard behaviour, thank you. I got same results on Adobe Acrobat 9 on Microsft Windows and Preview (5.0.3) on Mac OS X. Regards, mpsuzuki Werner LEMBERG wrote: FYI: I run into a regression issue with the latest FT (trunk) version. Attached is a sample font. I don't claim that this is a valid font however FT was able to render the file in 2.4.4 but not in 2.4.9. Hmm. I've just tried to render the PDF file with acroread 9.4.7 on my GNU/Linux box, and it doesn't show any glyphs... Werner ___ 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] Regression issue - CFF
Another followup for the standard behaviour. Although Adobe Acrobat 9 on Microsoft Windows does not show any glyphs for sample PDF, sample OTF can be browsed by fontview.exe (on Microsoft Windows XP SP2). Regards, mpsuzuki suzuki toshiya wrote (2012/04/14 21:23): Ah, I slipped to check what is the standard behaviour, thank you. I got same results on Adobe Acrobat 9 on Microsft Windows and Preview (5.0.3) on Mac OS X. Regards, mpsuzuki Werner LEMBERG wrote: FYI: I run into a regression issue with the latest FT (trunk) version. Attached is a sample font. I don't claim that this is a valid font however FT was able to render the file in 2.4.4 but not in 2.4.9. Hmm. I've just tried to render the PDF file with acroread 9.4.7 on my GNU/Linux box, and it doesn't show any glyphs... Werner ___ 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 inline: testotf.gif___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Amalgamation details
From: Alan Coopersmith alan.coopersm...@oracle.com A pretty convenient way to make your software full of security holes and other bugs if you don't spend the time to update it for every upstream patch, at which point you'll find that it's not all that convenient compared to just using a shared library. *sigh* people assume FreeType is only used for operating systems. How many times do I have to repeat the use-case for embedding both FreeType, and a font, within a desktop or smartphone application? For cases where the user cannot choose the font, there is no security hole. Amalgamation can be a way to make updating more convenient...Replacing old versions of freetype.c and freetype.h with newer versions of those same two files is far more convenient than replacing an old set of Freetype source files with a newer set, especially if files are renamed, removed, or added between versions. Right on! That's exactly what I'm talking about. My only concern about the amalgamated version of Freetype is that I don't know if it will continue to be maintained. For that reason, we haven't yet switched over to using the amalgamated version except experimentally. It will be maintained, and I have plans for improving the amalgamated distribution further. I've already added a feature for reducing the size of the result, to shave about 570kb off the FreeType amalgamation. I would also like to implement a config header file that lets certain portions of FreeType get turned off and on easily with preprocessor directives. And there will be a COMMITLOG file that tracks exactly what's in the amalgamation by quoting the entire commit log from which it was generated, along with proper tags in the git repository to refer to specific releases of FreeType. Currently, if I'm not mistaken, the amalgamation tool itself is not cross-platform. I haven't tried running it to produce the amalgamation myself. I've only tried using versions of freetype.c and freetype.h that Vinnie has made available. I would love to see the amalgamation tool become cross-platform and part of the Freetype project itself. Fully cross platform! The one thing that is not cross platform is the .bat file that drives it but that could be easily ported since its just a lot of command line switches.To get it into FreeType you would need the tool (which is itself just one source file, and one amalgamated multiplatform Juce module), the amalgamation templates, and a script to drive it. These are all open source. Before jumping to include it in the official distribution, I suggest giving it a week or two until I've made all the improvements I can make. Someone needed access to FT_Glyph which if I am not mistaken, is not available from a straight include of freetype.h. So I added the include to the amalgamated headers. If there are any other optional header files that I've forgotten let me know and I will add them. Also, if there is anything I can do to improve the amalgamated distribution I would be more than happy to do so. Thanks ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Amalgamation details
On 04/14/12 06:48 AM, Vinnie wrote: From: Alan Coopersmith alan.coopersm...@oracle.com A pretty convenient way to make your software full of security holes and other bugs if you don't spend the time to update it for every upstream patch, at which point you'll find that it's not all that convenient compared to just using a shared library. *sigh* people assume FreeType is only used for operating systems. How many times do I have to repeat the use-case for embedding both FreeType, and a font, within a desktop or smartphone application? For cases where the user cannot choose the font, there is no security hole. Do you know where most of the FreeType security issues in the past few years has been found? By people trying to hack smartphones via downloads of malicious PDF's or opening webpages with bad webfonts.Quite a few of the jailbreaks for Apple's iOS have resulted in FreeType security patches coming out - you can see credits to both Apple Google for providing fixes in the various advisories. Of course, those smartphone OS'es are providing system font rendering using FreeType so you don't have to shove in another copy there. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Amalgamation details
From: Alan Coopersmith alan.coopersm...@oracle.com Do you know where most of the FreeType security issues in the past few years has been found? By people trying to hack smartphones via downloads of malicious PDF's or opening webpages with bad webfonts. That's only a vulnerability of the application in question allows loading of arbitrary fonts. For the case where an application simply wants hinted output of its own font used in a user interface, with the entire font file embedded in the application as static data or a resource (100% of my users) there is no issue! Of course, those smartphone OS'es are providing system font rendering using FreeType so you don't have to shove in another copy there. I agree and its on my to-do list to refine the amalgamation so that it detects and uses the system provided library on environments where it exists. This behavior will be overridable with a configuration macro, for those people who have built a rich GUI on top of a hinted font and did all their testing with a specific version of FreeType, and don't want to be exposed to a bug in a shared FreeType library making their application look bad (for example, a defect discovered in the auto hinter). The end-game is to build rich open source GUI components on top of the FreeType amalgamation which will seamlessly provide FreeType either through the amalgamated sources or the system provided libraries (at the programmer's option), with the ability to distribute these GUI components without external dependencies (by including the amalgamation in the source distribution). All this, with no Makefiles or platform specific configuration required. In other words, for dummies. Of course it is worth repeating once again this use-case is contemplated ONLY FOR FONTS EMBEDDED IN THE APPLICATION and not for fonts which come from external files! I know this is a difficult concept for a lot of people who have no experience writing shrink-wrapped applications (which seem to be going the way of the Dodo) so here is an example (again): http://m.artician.com/pu/3G665GVDE5WXL3A7SOS6MP4RCOI6MJHB.preview.jpeg This is GUI for an audio plugin. These plugins typically have compact interfaces with small text, which is a great candidate for hinting. A plugin author can choose a good hinted font, embed it in their application (using a command tool that converts a binary file into a giant C-style static array), and then use FreeType to draw the font and get nice output at the small sizes. The benefit of using a statically linked FreeType is that you can design your interface, test it against the specific FreeType version, and then be assured that no matter what the user has on their system in terms of FreeType libraries, the application or plugin appearance will not change. Most audio plugins are built on JUCE (http://rawmaterialsoftware/juce.php) which is specifically tuned for making it easy to write cross platform user interfaces and audio plugins in particular. For this reason, I have built a class that works with the JUCE font rendererer to provide hinted output for embedded fonts: http://vinniefalco.github.com/VFLib/class_free_type_faces.html I hope this rant has helped to provide a broadened view of the variety of ways in which FreeType may be used. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] details
The next comment might be something like our target is not Android nor iOS or our application does not eat PDF nor web documents. I guess the background would not be by the characteristic of the system running in the target devices, it would be by the culture of the engineers. Regards, mpsuzuki Alan Coopersmith wrote: On 04/14/12 06:48 AM, Vinnie wrote: From: Alan Coopersmith alan.coopersm...@oracle.com A pretty convenient way to make your software full of security holes and other bugs if you don't spend the time to update it for every upstream patch, at which point you'll find that it's not all that convenient compared to just using a shared library. *sigh* people assume FreeType is only used for operating systems. How many times do I have to repeat the use-case for embedding both FreeType, and a font, within a desktop or smartphone application? For cases where the user cannot choose the font, there is no security hole. Do you know where most of the FreeType security issues in the past few years has been found? By people trying to hack smartphones via downloads of malicious PDF's or opening webpages with bad webfonts.Quite a few of the jailbreaks for Apple's iOS have resulted in FreeType security patches coming out - you can see credits to both Apple Google for providing fixes in the various advisories. Of course, those smartphone OS'es are providing system font rendering using FreeType so you don't have to shove in another copy there. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Amalgamation details
Vinnie, I support what you've done. It sounds very useful and as you say is not dangerous if used as intended. My choice in writing a cross-platform mapping library (CartoType) was to use a stable version of FreeType as an integral part of the CartoType library. I don't use any OS version of FreeType, or indeed any OS graphics primitives - to do so would invite trouble and inconsistency. By this means I get identical behaviour on all platforms. So it looks like I have the same constraints and aims as you. This way I keep my users happy and it's easier for me to maintain the code. Best regards, Graham Asher CartoType Ltd. On 14/04/2012 17:19, Vinnie wrote: From: Alan Coopersmithalan.coopersm...@oracle.com Do you know where most of the FreeType security issues in the past few years has been found? By people trying to hack smartphones via downloads of malicious PDF's or opening webpages with bad webfonts. That's only a vulnerability of the application in question allows loading of arbitrary fonts. For the case where an application simply wants hinted output of its own font used in a user interface, with the entire font file embedded in the application as static data or a resource (100% of my users) there is no issue! Of course, those smartphone OS'es are providing system font rendering using FreeType so you don't have to shove in another copy there. I agree and its on my to-do list to refine the amalgamation so that it detects and uses the system provided library on environments where it exists. This behavior will be overridable with a configuration macro, for those people who have built a rich GUI on top of a hinted font and did all their testing with a specific version of FreeType, and don't want to be exposed to a bug in a shared FreeType library making their application look bad (for example, a defect discovered in the auto hinter). The end-game is to build rich open source GUI components on top of the FreeType amalgamation which will seamlessly provide FreeType either through the amalgamated sources or the system provided libraries (at the programmer's option), with the ability to distribute these GUI components without external dependencies (by including the amalgamation in the source distribution). All this, with no Makefiles or platform specific configuration required. In other words, for dummies. Of course it is worth repeating once again this use-case is contemplated ONLY FOR FONTS EMBEDDED IN THE APPLICATION and not for fonts which come from external files! I know this is a difficult concept for a lot of people who have no experience writing shrink-wrapped applications (which seem to be going the way of the Dodo) so here is an example (again): http://m.artician.com/pu/3G665GVDE5WXL3A7SOS6MP4RCOI6MJHB.preview.jpeg This is GUI for an audio plugin. These plugins typically have compact interfaces with small text, which is a great candidate for hinting. A plugin author can choose a good hinted font, embed it in their application (using a command tool that converts a binary file into a giant C-style static array), and then use FreeType to draw the font and get nice output at the small sizes. The benefit of using a statically linked FreeType is that you can design your interface, test it against the specific FreeType version, and then be assured that no matter what the user has on their system in terms of FreeType libraries, the application or plugin appearance will not change. Most audio plugins are built on JUCE (http://rawmaterialsoftware/juce.php) which is specifically tuned for making it easy to write cross platform user interfaces and audio plugins in particular. For this reason, I have built a class that works with the JUCE font rendererer to provide hinted output for embedded fonts: http://vinniefalco.github.com/VFLib/class_free_type_faces.html I hope this rant has helped to provide a broadened view of the variety of ways in which FreeType may be used. ___ 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
[ft-devel] FreeType Amalgamation UPDATED!
I've updated the amalgamated version of FreeType, these are the changes: - The amalgamated repo is at https://github.com/vinniefalco/FreeTypeAmalgam - The repo no longer includes the templates - The directory structure has been flattened to make it easier to view - A file called COMMITLOG contains the full commit log of the branch of FreeType that was used to produce the corresponding amalgamated sources - The amalgamated files include the copyright and licensing terms at the top - The repo contains the license files - FreeTypeAmalgam.h provides ftglyph.h now The templates for building the FreeType amalgamation are in their own repository now, with these improvements: - The template repo is at https://github.com/vinniefalco/FreeTypeAmalgamTemplate - The script has been re-written to use the Bourne shell and placed in platform-independent location. - The Visual Studio 2010 project automatically creates the amalgamation as a pre-build step. - The amalgamation script automates production of COMMITLOG - Licensing terms (MIT license) were made clear The Amalgamate tool has also received some changes - The Amalgamate tool repo is at https://github.com/vinniefalco/Amalgamate - The directory structure has been flattened to make it easier to view and compile - The included JUCE module was shrunk down in size - The tool is cross platform (always was), it should be possible to just compile the two .cpp files and link them to create the binary. - Licensing terms were made clear Thanks ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Aftermath.
suzuki toshiya mpsuz...@hiroshima-u.ac.jp writes: Anyway, such discussion is out of the scope of the people saying i don't get why I feel as some people asking for a bread (or fermented paste) in the miller's market. Anyway, I'm sure all the relevant arguments were well-covered in the _previous_ flamewar on this topic... -miles -- Acquaintance, n. A person whom we know well enough to borrow from, but not well enough to lend to. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
