Re: [ft-devel] FreeType Engine
1- What compiler(s) would you say FreeType is compatible with? We are flexible enough to change compilers. FreeType is written in ANSI C, so basically all compilers should work. The problem is with compilers which are less than ANSI C... 2- Aside from scaling fonts at run time, what other capabilities FreeType has? None :-) FreeType's job is to render a glyph, nothing more. 3- Does the library have API calls to display texts, or draw graphical components, such as lines, boxes, filled boxes, etc? No. You need a higher-level library to do that because display of text strings can get extremely convoluted as soon as OpenType features are used. Look at Pango, Qt, or ICU. 4- Would the library work on any True Type Font? Essentially, yes. 5- What are the limits of how small or large the fonts can be scaled to? How large... Never tested that actually due to lack of memory :-) Tell me what you need and I tell you whether it works. How small... This depends on the font. However, any scalable font becomes illegible below 6ppem (pixels per EM) normally. 6- What is the cost of getting the library? It's unclear to me what you mean. In case you mean money: FreeType is freely available. 7- Is there a demo you can share, or setup a meeting to see the capabilities of FreeType, or give us a temporary version of the library to play with? FreeType comes with a bundle of demo programs, like ftview, which should compile on all major platforms. The latest tarballs are http://download.savannah.gnu.org/releases/freetype/freetype-2.4.8.tar.gz http://download.savannah.gnu.org/releases/freetype/freetype-doc-2.4.8.tar.gz http://download.savannah.gnu.org/releases/freetype/ft2demos-2.4.8.tar.gz For compilation on Windows (using non-GNU tools), however, you need zipped archives which have CR/LF line endings: http://download.savannah.gnu.org/releases/freetype/ft248.zip http://download.savannah.gnu.org/releases/freetype/ftdoc248.zip http://download.savannah.gnu.org/releases/freetype/ftdmo248.zip Note that we don't develop on Windows; this means that some project files might be out of date. BTW, if you need to see real-life usage of FreeType on ARM and similar chips, simply look at your favourite smartphone: Almost all of them use FreeType for rendering fonts, in particular everything using Android or iOS. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType License and patents
Are you willing to do the work to make sure no FreeType contributor currently has a patent on code they have contributed? This should be doable, given that there are just a handful of contributors who added longer, non-trivial stuff. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft] FreeType License and patents
Hello, Just to make it clear, I'm too in favor of adding an Apache2-like patent clause to the license. And for the sake of full-disclosure, my employer does releases quite a large amount http://source.android.com of Apache-2 licensed code. On Fri, Jan 13, 2012 at 8:34 PM, Eric Rannaud eric.rann...@gmail.comwrote: On Fri, Jan 13, 2012 at 11:16 AM, Dave Crossland d...@lab6.com wrote: On 13 January 2012 20:13, Werner LEMBERG w...@gnu.org wrote: I would like to add something similar, with the exception that code especially marked as patented within the FreeType source code is not covered. Comments? Why not just switch to Apache? Switching to Apache2 is an interesting possibility, but such a license change means getting the approval of all contributors to the project. Given FreeType's age, that might be challenging and/or time-consuming (e.g. what are the chances that all email addresses in our copyright disclaimers are still valid). An easier approach would be to ask for all future contributions to be covered by FreeType License 1.1, which would be equal to the actual one, plus a patent clause. This allows us to keep the existing code just as-is in case we don't have a contact or agreement with the original author of some piece of code. Also makes explaining the change easier. We can still continue to contact contributors to ask them their opinion/agreement on switching their existing code to Apache 2 though, and maybe later switch to it. Apache2 is not compatible with GPLv2 notably because of this particular patent clause (that's the general agreement anyway -- some see GPLv2 as already having an equivalent clause, albeit less explicit). Apache2 is compatible with GPLv3, however. GPL is already not an issue since the original FreeType license is not compatible either (due to the credit clause). That's why we dual-license the library by the way. I don't see why anything would change with the proposed license update. So you want to be careful adding that kind of exception, you may create a number of new license compatibility questions. If you want such a patent grant clause, you might as well have Freetype released under Apache2 and continue to make it available under GPLv2. At least license compatibility is then clear. However, by switching to Apache2, or by adding such a clause, you will likely make Freetype harder to use for some projects that may have liked the current license better. (e.g. OpenBSD: they don't like Apache2, and maybe would reject Freetype license + patent grant.) I'm ok with OpenBSD rejecting an updated license (you can't please all people in the world after all). I still can't find any official reason why they're opposed to Apache2, but they can still use the existing FreeType code and back-port security fixes manually if they want. They've been doing it with Apache 1 for years and nobody's been greatly impacted by it as far as I understand. It might be a good thing to bump the library's minor version number for the license change to make this back-tracking easier. - David ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft] FreeType License and patents
On 17 January 2012 09:25, David Turner di...@google.com wrote: An easier approach would be to ask for all future contributions to be covered by FreeType License 1.1, ... Apache2 is not compatible with GPLv2 notably because of this particular patent clause (that's the general agreement anyway -- some see GPLv2 as already having an equivalent clause, albeit less explicit). Apache2 is compatible with GPLv3, however. GPL is already not an issue since the original FreeType license is not compatible either (due to the credit clause). That's why we dual-license the library by the way. I don't see why anything would change with the proposed license update. But its GPLv2 only :-( Apache 2 is GPLv3 compatible. So I'd suggest either using Apache 2, or using FreeType License 1.1 and GPLv2-or-later. -- Cheers Dave ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft] FreeType License and patents
On Tue, Jan 17, 2012 at 3:53 PM, Dave Crossland d...@lab6.com wrote: But its GPLv2 only :-( Apache 2 is GPLv3 compatible. So I'd suggest either using Apache 2, or using FreeType License 1.1 and GPLv2-or-later. Apache 2 or GPLv2-or-later have the same problems: they require changing the license of existing code, i.e. contacting all copyright holders for permission, getting permissions from all of them or rewrite their contribution from scratch. I think it's easier/faster/simpler to start adding a new clause to cover any future contribution. The resulting package in its entirety would be covered by the 1.1 license, because the 1.0 one doesn't mandate restrictions on what you can do with the rest of the code (unlike the GPL). One option doesn't prevent the other, they just require different time frames. -- Cheers Dave ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)
Hi,
after I submitted my first patches I found a bunch of other PIC issues. I
see that you have fixed some of the same things I found too, mostly
missing includes to the various error-headerfiles, and a bunch of
unitialized variables for clazz and the various PIC modules, and pointer
dereferences of the same.
One example of that, there are plenty more:
diff --git a/modules/libfreetype/include/freetype/internal/ftdriver.h
b/modules/libfreetype/include/freetype/internal/ftdriver.h
index bbb9ddd..333f908 100644
--- a/modules/libfreetype/include/freetype/internal/ftdriver.h
+++ b/modules/libfreetype/include/freetype/internal/ftdriver.h
@@ -366,11 +366,11 @@ FT_BEGIN_HEADER
FT_Create_Class_##class_( FT_Library
library, \
FT_Module_Class** output_class
)\
{
\
-FT_Driver_Class
clazz; \
+FT_Driver_Class clazz =
NULL; \
FT_Error
error; \
FT_Memorymemory =
library-memory; \
\
-if ( FT_ALLOC( clazz, sizeof(*clazz) )
) \
+if ( FT_ALLOC( clazz, sizeof(FT_Driver_ClassRec) )
) \
return
error; \
\
error = class_##_pic_init( library
);\
If you prefer I can send another patch with those changes.
Regarding testing of the PIC mode, yes you can test it on Linux even
though PIC isn't normally required there. The linker that has issues with
strings and array initializations like in ftobjs.c is for the Brew
platform.
On Tue, 17 Jan 2012 07:54:40 +0100, suzuki toshiya
mpsuz...@hiroshima-u.ac.jp wrote:
During the overhaul for PIC build, I found that cache subsystem
of FreeType2 is not ready for PIC build, thus the demo programs
doing rasterization (e.g. ftview, ftbench) cannot be built.
Thus I can check if the code is compilable, but cannot check
if the code is working. Maybe most expected direction is the
porting of the cache subsystem for PIC build (even if there is
no real user of it on embedded system), but extending some demo
programs for FreeType2 without cache subsystem would be easier
first step.
# I assume FreeType2 built in PIC mode will work in the operating
# system that PIC mode is NOT required (e.g. Linux). If it's
# misunderstanding, please let me know.
Any comments?
Regards,
mpsuzuki
suzuki toshiya wrote:
Dear Erik,
I have made some overhaul for PIC build, and, your patch to
modify resource fork support for PIC build is applied with
some coding style changing. Please check whether GIT head
works on your platform.
BTW,
diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
index 1a5a327..fc687f5 100644
--- a/src/base/ftobjs.c
+++ b/src/base/ftobjs.c
@@ -4533,7 +4533,9 @@
*/
{
FT_UInt m, n;
- const char* driver_name[] = { type42, NULL };
+ const char* driver_name[2];
+ driver_name[0] = type42;
+ driver_name[1] = NULL;
for ( m = 0;
is not committed yet, because I want to know which linker complains
about such initialization. If possible, please let me know 1 example
to be documented in ChangeLog. I'm not saying there should not be
such linker, just I want to know 1 example, for good documentation.
Sorry for troubling you.
Regards,
mpsuzuki
suzuki toshiya wrote:
Dear Erik,
Sorry for your trouble and thank you for providing a patch,
I will check it in this weekend. Please give me a few days.
Regards,
mpsuzuki
Werner LEMBERG wrote:
The commits in question are both dealing with compilation of
'complex' structures and static globals.
Thanks for the patch. Toshiya-san, can you have a look and take care
of it, please?
Werner
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)
Dear Erik,
Of course, I want to receive the patch to improve (rather,
I should call restore) PIC build. I wish if my overhaul
have not made you troubled.
Erik Dahlstrom wrote:
diff --git a/modules/libfreetype/include/freetype/internal/ftdriver.h
b/modules/libfreetype/include/freetype/internal/ftdriver.h
index bbb9ddd..333f908 100644
--- a/modules/libfreetype/include/freetype/internal/ftdriver.h
+++ b/modules/libfreetype/include/freetype/internal/ftdriver.h
@@ -366,11 +366,11 @@ FT_BEGIN_HEADER
FT_Create_Class_##class_( FT_Library
library, \
FT_Module_Class** output_class
)\
{
\
-FT_Driver_Class
clazz; \
+FT_Driver_Class clazz =
NULL; \
FT_Error
error; \
FT_Memorymemory =
library-memory; \
\
-if ( FT_ALLOC( clazz, sizeof(*clazz) )
) \
+if ( FT_ALLOC( clazz, sizeof(FT_Driver_ClassRec) )
) \
return
error; \
\
error = class_##_pic_init( library
);\
If you prefer I can send another patch with those changes.
Ahhh... although I'm not sure whether ANSI C requests that
sizeof(*xxx_p) works as sizeof(xxx), I think such modification
is not bad idea. BTW, sizeof(*xxx_p) style coding is refused
by the compiler? or linker?
Regarding testing of the PIC mode, yes you can test it on Linux even
though PIC isn't normally required there. The linker that has issues
with strings and array initializations like in ftobjs.c is for the Brew
platform.
Thanks. I heard that BREW's official SDK is based on ARM RVCT
compiler in Microsoft Visual C++ IDE. I don't have MSVC IDE,
but I will check if there is any free-charged version of RVCT
compiler.
Regards,
mpsuzuki
On Tue, 17 Jan 2012 07:54:40 +0100, suzuki toshiya
mpsuz...@hiroshima-u.ac.jp wrote:
During the overhaul for PIC build, I found that cache subsystem
of FreeType2 is not ready for PIC build, thus the demo programs
doing rasterization (e.g. ftview, ftbench) cannot be built.
Thus I can check if the code is compilable, but cannot check
if the code is working. Maybe most expected direction is the
porting of the cache subsystem for PIC build (even if there is
no real user of it on embedded system), but extending some demo
programs for FreeType2 without cache subsystem would be easier
first step.
# I assume FreeType2 built in PIC mode will work in the operating
# system that PIC mode is NOT required (e.g. Linux). If it's
# misunderstanding, please let me know.
Any comments?
Regards,
mpsuzuki
suzuki toshiya wrote:
Dear Erik,
I have made some overhaul for PIC build, and, your patch to
modify resource fork support for PIC build is applied with
some coding style changing. Please check whether GIT head
works on your platform.
BTW,
diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
index 1a5a327..fc687f5 100644
--- a/src/base/ftobjs.c
+++ b/src/base/ftobjs.c
@@ -4533,7 +4533,9 @@
*/
{
FT_UInt m, n;
- const char* driver_name[] = { type42, NULL };
+ const char* driver_name[2];
+ driver_name[0] = type42;
+ driver_name[1] = NULL;
for ( m = 0;
is not committed yet, because I want to know which linker complains
about such initialization. If possible, please let me know 1 example
to be documented in ChangeLog. I'm not saying there should not be
such linker, just I want to know 1 example, for good documentation.
Sorry for troubling you.
Regards,
mpsuzuki
suzuki toshiya wrote:
Dear Erik,
Sorry for your trouble and thank you for providing a patch,
I will check it in this weekend. Please give me a few days.
Regards,
mpsuzuki
Werner LEMBERG wrote:
The commits in question are both dealing with compilation of
'complex' structures and static globals.
Thanks for the patch. Toshiya-san, can you have a look and take care
of it, please?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
