Re: help needed for cmake problem (FreeType issue #897)

[Tom Kacvinsky]

Hi Werner,

I work extensively with cmake at my day job.  If the end consumer of
FreeType wants
to build their project using cmake, the there would be a need to make
cmake module
that could be used with cmake (which, to my delight, already exists).
The the user
could know how to link in bzip2 (there's plenty of tutorials on how to
do that since bzip2
doesn't have a pkgconfig file).

So I think the thrust of this issue is when people want to build
outside of cmake, and
the corresponding freetype.pc file can't find bzip2.pc.  SOme distros
have made .pc
files for bzip2 via patches to upstream, but for the life of me, I
don't understand _why_
they haven't submitted them for inclusion to bzip2.  In any case, that
does no good for
distributions that haven't taken the latest upstream.

But bzip2 seems to be pretty lightweight and has a license that
appears to be amenable
to the FreeType license, so why not just add it to the repo?

On Thu, Jan 27, 2022 at 12:44 PM Werner LEMBERG  wrote:
>
>
> While walking over open FreeType issues I wondered whether there is a
> cmake expert who could fix issue #897, a problem with generating a
> potentially invalid `.pc` file because 'bzip2' doesn't come with a
> `.pc` file of its own by default:
>
>   https://gitlab.freedesktop.org/freetype/freetype/-/issues/897
>
> Anyone?  My cmake skills are veery limited...
>
>
> Werner
>

Problems building freetype-2.10.4 on CentOS 5 with GCC 8.3.0

[Tom Kacvinsky]

I see this

-bash-3.2$ make
./builds/unix/libtool --mode=compile gcc -pedantic -ansi
-I/home/LOCAL/tjk/freetype-2.10.4/objs -I./builds/unix
-I/home/LOCAL/tjk/freetype-2.10.4/include  -c -Wall -g -O2
-fvisibility=hidden   -I -DFT_CONFIG_CONFIG_H=""
-DFT_CONFIG_MODULES_H="" -DFT_CONFIG_OPTIONS_H=""
-DFT2_BUILD_LIBRARY -o /home/LOCAL/tjk/freetype-2.10.4/objs/ftsystem.lo
builds/unix/ftsystem.c
libtool: compile:  gcc -pedantic -ansi
-I/home/LOCAL/tjk/freetype-2.10.4/objs -I./builds/unix
-I/home/LOCAL/tjk/freetype-2.10.4/include -c -Wall -g -O2
-fvisibility=hidden -I "-DFT_CONFIG_CONFIG_H="
"-DFT_CONFIG_MODULES_H=" "-DFT_CONFIG_OPTIONS_H="
-DFT2_BUILD_LIBRARY builds/unix/ftsystem.c -o
/home/LOCAL/tjk/freetype-2.10.4/objs/ftsystem.o
builds/unix/ftsystem.c: In function ‘FT_Stream_Open’:
builds/unix/ftsystem.c:241:12: warning: implicit declaration of function
‘open’; did you mean ‘fopen’? [-Wimplicit-function-declaration]
 file = open( filepathname, O_RDONLY );
^~~~
fopen
builds/unix/ftsystem.c:241:32: error: ‘O_RDONLY’ undeclared (first use in
this function)
 file = open( filepathname, O_RDONLY );
^~~~
builds/unix/ftsystem.c:241:32: note: each undeclared identifier is reported
only once for each function it appears in
builds/unix/ftsystem.c:325:22: warning: implicit declaration of function
‘read’; did you mean ‘fread’? [-Wimplicit-function-declaration]
 read_count = read( file,
  ^~~~
  fread
builds/unix/ftsystem.c:346:5: warning: implicit declaration of function
‘close’; did you mean ‘fclose’? [-Wimplicit-function-declaration]
 close( file );
 ^
 fclose

Configured with
/configure --prefix=/path/to/freetype-2.10.4 --disable-shared 2>&1 | tee
conf.log

This makes zero sense since perusing the FreeType header files, the
necessary include files
for read and close and there.

Any ideas?  Using GNU Make 3.81.  Read docs/INStALL.UNIX and I think I have
met all of the prerequisites.

Re: [ft-devel] Time for a new FreeType release

[Tom Kacvinsky]

What I was thinking of doing is finalizing the work necessary to get a
symbol versioning linker script in place, but it is not necessary for this
release.  It is just a "nice to have"

So I'd say the lack of such feature won't delay the release.

On Sun, Apr 8, 2018 at 11:37 AM, Nikolaus Waxweiler 
wrote:

> Do you mean there's something else to do for versioning?
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Tom Kacvinsky]

Hi,

I dropped the ball.  I meant to get to the symbol versioning stuff we
talked about so we'd have it for this release, but I've been swamped
with work.

Tom

On Sun, Apr 8, 2018 at 9:21 AM, Werner LEMBERG  wrote:

>
> > Got it working :) Tested with CMake 3.10.2 on Win 10 x64. Version
> > and copyright information was shown in the details tab of the file
> > properties dialog.
>
> Great!
>
> Nikolaus, I've just given you write permission to the FreeType
> repositories (user `madleser').  Please commit the CMake stuff,
> together with proper ChangeLog entries.
>
>
> 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] LD version script

[Tom Kacvinsky]

OK, I looked over the script and it make sense as to what it is doing - it
is iterating over the various
branches used to build FreeType.  However, I know from SUSE packaging
needs, the build of FT
for SUSE packages is based on the tarball and patches to be applied against
the tarball (you can
see this in the openSUSE Open Build System (build.opensuse.org) for
ghostscript.  So I propose
as part of the final packaging for a release, we check in the symbol
version script and provide a
patch that can be applied against the tarball.  Or leave in the libtool
options for using the version
script on GNU/Linux and Solaris, and have the version script checked in.
The reason for this is I
don't think that build systems will do a git clone and run the various
scripts for symbol versioning
generation.

I can check on this, though. Behdad might have some input from how this is
handled on the Red Hat
side of things.

Tom

On Sat, Feb 3, 2018 at 8:05 AM, Tom Kacvinsky  wrote:

> I am really stupid, I see it was attached to this mail thread.
>
>
> On Sat, Feb 3, 2018 at 8:04 AM, Werner LEMBERG  wrote:
>
>>
>> > I have the latest master repository cloned. and cannot find a
>> > symvergen script it in.  I pulled again to make sure I had the
>> > latest, and didn't see it.  Moreover I ran "git branch" to see if
>> > there was a different branch into which the symvergen script would
>> > go, and did not see it.
>> >
>> > What am I missing here?
>>
>> Alexei has posted it to the mailing list, cf.
>>
>>   https://lists.gnu.org/archive/html/freetype-devel/2018-02/msg1.html
>>
>>
>> Werner
>>
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Tom Kacvinsky]

I am really stupid, I see it was attached to this mail thread.


On Sat, Feb 3, 2018 at 8:04 AM, Werner LEMBERG  wrote:

>
> > I have the latest master repository cloned. and cannot find a
> > symvergen script it in.  I pulled again to make sure I had the
> > latest, and didn't see it.  Moreover I ran "git branch" to see if
> > there was a different branch into which the symvergen script would
> > go, and did not see it.
> >
> > What am I missing here?
>
> Alexei has posted it to the mailing list, cf.
>
>   https://lists.gnu.org/archive/html/freetype-devel/2018-02/msg1.html
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Tom Kacvinsky]

Hi Werner, Alexei,

I have the latest master repository cloned. and cannot find a symvergen
script it in.  I pulled again
to make sure I had the latest, and didn't see it.  Moreover I ran "git
branch" to see if there was a
different branch into which the symvergen script would go, and did not see
it.

What am I missing here?

Tom


On Sat, Feb 3, 2018 at 12:58 AM, Werner LEMBERG  wrote:

>
> > I looked aver the changes apinames.c to see how the GNU and Solaris
> > linker version script is handled.
>
> Good, but...
>
> > The question I have is how are we going to add the actual symbol
> > versions - read in a version tag or something else?.  Also, how are
> > we going to handle inheritance?, For instance, using 1.2 as a sample
> > version number and FT as the tag: [...]
>
> ... this sounds as if you haven't looked at Alexei's script!  For
> example, running it with the current repository creates the attached
> data.
>
> > Or is the FT API immutable, and never going to change?
>
> We try to not change the API in any way, only adding symbols (and
> fixing bugs, of course).  Ditto for public structures.
>
>
> Werner
>
> FREETYPE_2.2.0 {
> global:
> FTC_CMapCache_Lookup;
> FTC_CMapCache_New;
> FTC_ImageCache_Lookup;
> FTC_ImageCache_New;
> FTC_Manager_Done;
> FTC_Manager_LookupFace;
> FTC_Manager_LookupSize;
> FTC_Manager_Lookup_Face;
> FTC_Manager_Lookup_Size;
> FTC_Manager_New;
> FTC_Manager_RemoveFaceID;
> FTC_Manager_Reset;
> FTC_Node_Unref;
> FTC_SBitCache_Lookup;
> FTC_SBitCache_New;
> FT_Activate_Size;
> FT_Add_Default_Modules;
> FT_Add_Module;
> FT_Angle_Diff;
> FT_Atan2;
> FT_Attach_File;
> FT_Attach_Stream;
> FT_Bitmap_Convert;
> FT_Bitmap_Copy;
> FT_Bitmap_Done;
> FT_Bitmap_Embolden;
> FT_Bitmap_New;
> FT_CeilFix;
> FT_ClassicKern_Free;
> FT_ClassicKern_Validate;
> FT_Cos;
> FT_DivFix;
> FT_Done_Face;
> FT_Done_FreeType;
> FT_Done_Glyph;
> FT_Done_Library;
> FT_Done_Size;
> FT_FloorFix;
> FT_GetFile_From_Mac_ATS_Name;
> FT_GetFile_From_Mac_Name;
> FT_Get_BDF_Charset_ID;
> FT_Get_BDF_Property;
> FT_Get_CMap_Language_ID;
> FT_Get_Char_Index;
> FT_Get_Charmap_Index;
> FT_Get_First_Char;
> FT_Get_Glyph;
> FT_Get_Glyph_Name;
> FT_Get_Kerning;
> FT_Get_MM_Var;
> FT_Get_Module;
> FT_Get_Multi_Master;
> FT_Get_Name_Index;
> FT_Get_Next_Char;
> FT_Get_PFR_Advance;
> FT_Get_PFR_Kerning;
> FT_Get_PFR_Metrics;
> FT_Get_PS_Font_Info;
> FT_Get_PS_Font_Private;
> FT_Get_Postscript_Name;
> FT_Get_Renderer;
> FT_Get_Sfnt_Name;
> FT_Get_Sfnt_Name_Count;
> FT_Get_Sfnt_Table;
> FT_Get_SubGlyph_Info;
> FT_Get_Track_Kerning;
> FT_Get_TrueType_Engine_Type;
> FT_Get_WinFNT_Header;
> FT_Get_X11_Font_Format;
> FT_GlyphSlot_Embolden;
> FT_GlyphSlot_Oblique;
> FT_GlyphSlot_Own_Bitmap;
> FT_Glyph_Copy;
> FT_Glyph_Get_CBox;
> FT_Glyph_Stroke;
> FT_Glyph_StrokeBorder;
> FT_Glyph_To_Bitmap;
> FT_Glyph_Transform;
> FT_Has_PS_Glyph_Names;
> FT_Init_FreeType;
> FT_Library_Version;
> FT_List_Add;
> FT_List_Finalize;
> FT_List_Find;
> FT_List_Insert;
> FT_List_Iterate;
> FT_List_Remove;
> FT_List_Up;
> FT_Load_Char;
> FT_Load_Glyph;
> FT_Load_Sfnt_Table;
> FT_Matrix_Invert;
> FT_Matrix_Multiply;
> FT_MulDiv;
> FT_MulFix;
> FT_New_Face;
> FT_New_Face_From_FOND;
> FT_New_Face_From_FSRef;
> FT_New_Face_From_FSSpec;
> FT_New_Library;
> FT_New_Memory_Face;
> FT_New_Size;
> FT_OpenType_Free;
> FT_Op

Re: [ft-devel] LD version script

[Tom Kacvinsky]

I looked aver the changes apinames.c to see how the GNU and Solaris linker
version script is handled.

The question I have is how are we going to add the actual symbol versions -
read in a version tag or
something else?.  Also, how are we going to handle inheritance?, For
instance, using 1.2 as a sample
version number and FT as the tag:

FT_1.2 {
  global:
 new_sym1:
 new_sym2;
  local:
.*;
} FT_1.1;

FT_1.1
   global:
   # all syms for 1.1 release
   local:
 .*;
};

so that 1.2 has all the symbols added to the 1.2 API and inherit the rest
from the 1.1 API.

Or is the FT API immutable, and never going to change?


On Fri, Feb 2, 2018 at 1:40 AM, Werner LEMBERG  wrote:

>
> > Again, the symbol versioning does not improve performance, the
> > attribute does.
>
> Yep.  However, the benefits for FreeType are rather small, I believe,
> since the number of library functions is small.
>
> > I am attaching my slightly updated script. We need to discuss the
> > tag, FREETYPE or FT or FreeType if it is legal.
>
> The script works fine, thanks!  Whom could we ask which the tag prefix
> is valid?
>
> > I will work on -fvisibility=hidden support through AC_TRY_COMPILE.
>
> Thanks.
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Tom Kacvinsky]

Ah, I was reading the following and came across something that is an
argument against version scripts.

https://gcc.gnu.org/wiki/Visibility

In particular: "Furthermore, using linker version scripts doesn't permit
GCC to better optimise the code."

On Wed, Jan 31, 2018 at 3:41 PM, Tom Kacvinsky  wrote:

> Just let me know if you want me to proceed.  I am not going to spend the
> time on this if the consensus (sans me) is that we don't need/want it.
>
> On Wed, Jan 31, 2018 at 3:22 AM, Werner LEMBERG  wrote:
>
>>
>> > I also hated the frontend of the symbol versions which requires GCC
>> > assembler trickery.
>> >
>> >   https://gcc.gnu.org/wiki/SymbolVersioning
>> >
>> > This is a can of warms, which I do not want to open.
>>
>> I guess we don't need this.
>>
>> > I have started this when I saw that libtool wraps the flat file of
>> > symbols to export into an anonymous version script.  That seemed
>> > weird.  Right now I would actually prefer
>> > __attribute__((__visibility__("default"))) to any list, as gcc and
>> > Vincent suggest
>> >
>> >   https://www.gnu.org/software/gnulib/manual/html_node/Export
>> ed-Symbols-of-Shared-Libraries.html
>> >   http://lists.nongnu.org/archive/html/freetype-devel/2018-
>> 01/msg00067.html
>>
>> I don't object, and it could be integrated into the `FT_EXPORT' macro,
>> AFAICS.  However, this doesn't give versioned symbols.  IIRC, Drepper
>> recommends to use both approaches: the `__visibility__' attribute
>> improves code generation of the compiler, and the map file provides
>> symbol versioning.
>>
>>
>> Werner
>>
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Tom Kacvinsky]

Just let me know if you want me to proceed.  I am not going to spend the
time on this if the consensus (sans me) is that we don't need/want it.

On Wed, Jan 31, 2018 at 3:22 AM, Werner LEMBERG  wrote:

>
> > I also hated the frontend of the symbol versions which requires GCC
> > assembler trickery.
> >
> >   https://gcc.gnu.org/wiki/SymbolVersioning
> >
> > This is a can of warms, which I do not want to open.
>
> I guess we don't need this.
>
> > I have started this when I saw that libtool wraps the flat file of
> > symbols to export into an anonymous version script.  That seemed
> > weird.  Right now I would actually prefer
> > __attribute__((__visibility__("default"))) to any list, as gcc and
> > Vincent suggest
> >
> >   https://www.gnu.org/software/gnulib/manual/html_node/
> Exported-Symbols-of-Shared-Libraries.html
> >   http://lists.nongnu.org/archive/html/freetype-devel/
> 2018-01/msg00067.html
>
> I don't object, and it could be integrated into the `FT_EXPORT' macro,
> AFAICS.  However, this doesn't give versioned symbols.  IIRC, Drepper
> recommends to use both approaches: the `__visibility__' attribute
> improves code generation of the compiler, and the map file provides
> symbol versioning.
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Tom Kacvinsky]

Well, that is inspirational enough - let's be the first to do historical
versioning instead of slapping a single
version on each symbol with each iteration of the API.

I mean, I am willing to do the work, so I am guessing your hesitance is
more based on the principle of the
matter, not the additional work it would take (since I am going to do it).

On Tue, Jan 30, 2018 at 4:40 PM, Alexei Podtelezhnikov 
wrote:

>
>
> On Tue, Jan 30, 2018 at 3:30 PM, Behdad Esfahbod 
> wrote:
>
>> I want to hear from downstreams that want to add symbol-versioning to
>> FreeType first, why do they need to.
>>
>
> I need some inspiration, some good examples to follow. Besides glibc, so
> far I've only seen silly wrappers that slap a single version on all symbols
> regardless of history.
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Tom Kacvinsky]

You raise a fair point.  The point I was trying to make, and perhaps I
didn't make it clear enough
what I was after, is this: suppose some downstream maintainer decides to
add symbol versions.
Wouldn't it be nice if we already had that so there is no mess between how
one Linux distribution
does it versus another?  Granted, there still might be a mess, but we can
mitigate the hassle.

And, now for another idiom:  that's just my two cents.

Regards,

Tom

On Tue, Jan 30, 2018 at 3:03 PM, Behdad Esfahbod 
wrote:

> I know what symbol versioning is used for (I was also package maintainer
> at Red Hat for four years). But don't see how it applies to FreeType.
> FreeType never changes ABI in backward-incompatible way. Its build system
> is already adhoc enough. I don't want to see more complexity added
> unnecessarily. Also, I don't want FreeType binaries to come with the same
> headaches that libpng and openssl cause every time they bump soname.
>
> On Tue, Jan 30, 2018 at 4:45 AM, Tom Kacvinsky  wrote:
>
>> Hi all,
>>
>> I'll see what I can do.  To be honest, the only platforms that really
>> support this
>> are Linux and Solaris.  I definitely have access to Linux machines, but
>> not a
>> Solaris machine.  I might be able to get access to the latter.
>>
>> Despite all of the talk about whether symbol versioning is useful (and
>> this is not
>> meant to be snarky), keep in mind the major commercial Linux
>> distributions use
>> symbol versioning, as well as the free Linux distributions.  I work for
>> SUSE and
>> my colleagues highly recommend getting symbol versioning into FreeType.  I
>> agree with them and am willing to do the work as I find time -  as the
>> saying goes,
>> put my money where my mouth is.
>>
>> The only thing I would need is a way of getting the API functions to add
>> to a
>> symbol versioning linker file.  This way, the symbol versioning script
>> doesn't
>> need to be checked in, and if we add something to the API, we don't need
>> to
>> worry about missing it in the library version file.
>>
>> Regards,
>>
>> Tom
>>
>> On Tue, Jan 30, 2018 at 1:25 AM, Werner LEMBERG  wrote:
>>
>>>
>>> > Admittedly, symbol versioning is very poorly supported and
>>> > documented [...]
>>>
>>> Yes.
>>>
>>> > [...] All in all, this looks like something to stay away from.
>>>
>>> Maybe there are more knowledgeable people who want to contribute...
>>>
>>>
>>> Werner
>>>
>>
>>
>> ___
>> Freetype-devel mailing list
>> Freetype-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>
>>
>
>
> --
> behdad
> http://behdad.org/
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Tom Kacvinsky]

Well, if Solaris for x86_64 is freely available and uses symbol versioning
exactly the same way
Solaris for SPARC does, I can got hat route.  What I was after is I might
be able to get access
to SPARC bare metal hardware with Solaris 8, 9 or 10.

On Tue, Jan 30, 2018 at 7:48 AM, Vincent Torri 
wrote:

> On Tue, Jan 30, 2018 at 1:45 PM, Tom Kacvinsky  wrote:
> > Hi all,
> >
> > I'll see what I can do.  To be honest, the only platforms that really
> > support this
> > are Linux and Solaris.  I definitely have access to Linux machines, but
> not
> > a
> > Solaris machine.  I might be able to get access to the latter.
>
> virtualbox + openindiana ?
>
> Vincent Torri
>
> > Despite all of the talk about whether symbol versioning is useful (and
> this
> > is not
> > meant to be snarky), keep in mind the major commercial Linux
> distributions
> > use
> > symbol versioning, as well as the free Linux distributions.  I work for
> SUSE
> > and
> > my colleagues highly recommend getting symbol versioning into FreeType.
> I
> > agree with them and am willing to do the work as I find time -  as the
> > saying goes,
> > put my money where my mouth is.
> >
> > The only thing I would need is a way of getting the API functions to add
> to
> > a
> > symbol versioning linker file.  This way, the symbol versioning script
> > doesn't
> > need to be checked in, and if we add something to the API, we don't need
> to
> > worry about missing it in the library version file.
> >
> > Regards,
> >
> > Tom
> >
> > On Tue, Jan 30, 2018 at 1:25 AM, Werner LEMBERG  wrote:
> >>
> >>
> >> > Admittedly, symbol versioning is very poorly supported and
> >> > documented [...]
> >>
> >> Yes.
> >>
> >> > [...] All in all, this looks like something to stay away from.
> >>
> >> Maybe there are more knowledgeable people who want to contribute...
> >>
> >>
> >> 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] LD version script

[Tom Kacvinsky]

Hi all,

I'll see what I can do.  To be honest, the only platforms that really
support this
are Linux and Solaris.  I definitely have access to Linux machines, but not
a
Solaris machine.  I might be able to get access to the latter.

Despite all of the talk about whether symbol versioning is useful (and this
is not
meant to be snarky), keep in mind the major commercial Linux distributions
use
symbol versioning, as well as the free Linux distributions.  I work for
SUSE and
my colleagues highly recommend getting symbol versioning into FreeType.  I
agree with them and am willing to do the work as I find time -  as the
saying goes,
put my money where my mouth is.

The only thing I would need is a way of getting the API functions to add to
a
symbol versioning linker file.  This way, the symbol versioning script
doesn't
need to be checked in, and if we add something to the API, we don't need to
worry about missing it in the library version file.

Regards,

Tom

On Tue, Jan 30, 2018 at 1:25 AM, Werner LEMBERG  wrote:

>
> > Admittedly, symbol versioning is very poorly supported and
> > documented [...]
>
> Yes.
>
> > [...] All in all, this looks like something to stay away from.
>
> Maybe there are more knowledgeable people who want to contribute...
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Tom Kacvinsky]

I suggest you read Ulrich Drepper's article on what symbol versioning
addresses.  FreeType is not known
for frequently changing its ABI or API (I don't think I've ever recalled
the former happening), so some of
these things are not relevant to the FreeType project.  Still, I think it
would be a good thing to have for
downstream consumers - I am thinking of Linux distributions, which have
been known to add symbol
versioning to libraries that don't have it.  OpenSSL comes to mind, though
the OpenSSL folks now offer
symbol versioning.  If Linux distributions are going to add, it raises the
question of how how they go
about it and change the SONAME.  Better to have it consistent upstream for
those who desire to have
symbol versioning.


On Sun, Jan 28, 2018 at 7:56 PM, Behdad Esfahbod 
wrote:

> If none of us know what problem this is fixing, maybe you shouldn't make
> any changes.
>
> On Sun, Jan 28, 2018 at 1:43 PM, Werner LEMBERG  wrote:
>
>>
>> >>> I would consider, maybe, providing the version mapfile in the
>> >>> builds/unix/ folder, with regular upgrades as a part of the
>> >>> release cycle.
>> >>
>> >> Hmm.  Maybe it makes more sense to simply call the script during
>> >> `make dist', additionally having a Makefile rule to (re)generate
>> >> it.
>> >
>> > You’d need git repository.
>>
>> Yes.
>>
>> > It is either we distribute the map file or we don’t.
>>
>> In a release tarball we would have the file, but probably not in git.
>>
>>
>> Werner
>> ___
>> Freetype-devel mailing list
>> Freetype-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>
>
>
>
> --
> behdad
> http://behdad.org/
>
> ___
> 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] LD version script

[Tom Kacvinsky]

We should be careful to notify downstream consumers of FreeType as some
Linux vendors
may already do symbol versioning in their implementations of it - any
changes we make may
have an effect on what they're doing.




On Wed, Jan 24, 2018 at 7:33 AM, Werner LEMBERG  wrote:

>
> > I've just found out that libtool wraps the --export-symbols file
> > into a --Wl,--version- script file, perhaps because of this paper
> > . That got me reading
> > further about version/symbol maps or scripts, which can keep track
> > on newly added interfaces. So I generated one for FreeType using
> > git, attached.
>
> Interesting, thanks!
>
> > It works and does decorate the shared library with version tags. The
> > file skips over FT versions that did not introduce any new
> > symbols. so the format might be slightly wrong.
> >
> > The file is interesting from historical perspective too, but I am
> > not sure about actual benefits.  Should we consider it further?
>
> Good question.  I've never seen this before, and I have no idea what
> to do with that information...
>
>
> 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

[ft-devel] Meltdown and Spectre

[Tom Kacvinsky]

Anyone here know if FreeType is immune to Spectre and Meltdown?  Or is
there something we have to do?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

[Tom Kacvinsky]

Agreed.  Windows is fussy about memory allocated in one DLL being freed in
another.


On Wed, Dec 13, 2017 at 9:57 AM, Cosimo Lupo  wrote:

> IMO, what matters is not which specific memory allocator/deallocator is
> used (whether the defaults, or user provided ones), but that they match
> with one another (they are defined by the same library).
>
> That’s why I like the simplicity of a TTF_autohint_done function.
>
> That’s just a one liner.
>
>
> --
>
>
> Cosimo
>
>
> Il 13 dic 2017, 13:44 +, Werner LEMBERG , ha scritto:
>
>
> Hello Tom!
>
>
> Have you considered CFFI? [1]
>
> This might make things a little easier, but I am not sure since I
> don't have as much experience with that as I do ctypes. Or are you
> more or less married to ctypes?
>
>
> Well, I guess this doesn't make a difference on the ttfautohint
> library side... So I still have to decide whether to add pointers to
> allocation and deallocation functions, or to add an explicit
> `TTF_autohint_done' function.
>
>
> Werner
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

[Tom Kacvinsky]

Have you considered CFFI? [1]

This might make things a little easier, but I am not sure since I don't
have as much experience with that as I do ctypes.
Or are you more or less married to ctypes?

[1] https://cffi.readthedocs.io/en/latest/

On Wed, Dec 13, 2017 at 7:23 AM, Werner LEMBERG  wrote:

>
> >> What do you think about providing function pointers to TTF_autohint
> >> for memory allocation and deallocation instead?
> >
> > it's bit more complicated to pass a function pointer with ctypes,
> > but it's possible.  Whatever you think is best,
>
> Well, I simply don't know what is best.  I can imagine that it is
> beneficial to have a single memory allocation routine for both the DLL
> and the caller for garbage collection stuff and the like, but maybe
> I'm completely wrong...
>
> Any other opinions?
>
>
> 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] ft2build.h being regenerated each time.

[Tom Kacvinsky]

You can try building the GNU install program (or get it from macports or
fink or some such) and adding the location to it to your path and try again.


On Fri, Apr 5, 2013 at 10:12 AM, Tom Kacvinsky  wrote:

> I think the issue here might be related to the fact that Mac Os X uses the
> BSD install program, but Linux uses the GNU install program.
>
>
> On Fri, Apr 5, 2013 at 8:14 AM, Werner LEMBERG  wrote:
>
>>
>> > I have noticed similar behaviour from libpng, but I'm also planning
>> > to switch to CMake for building libpng, I wonder if it has the same
>> > issue or not?
>>
>> I think that you will find this issue everywhere.  But maybe I'm
>> wrong.
>>
>>
>> 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] ft2build.h being regenerated each time.

[Tom Kacvinsky]

I think the issue here might be related to the fact that Mac Os X uses the
BSD install program, but Linux uses the GNU install program.


On Fri, Apr 5, 2013 at 8:14 AM, Werner LEMBERG  wrote:

>
> > I have noticed similar behaviour from libpng, but I'm also planning
> > to switch to CMake for building libpng, I wonder if it has the same
> > issue or not?
>
> I think that you will find this issue everywhere.  But maybe I'm
> wrong.
>
>
> 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] Fonts with unusual CFF operators sought!

[Tom Kacvinsky]

Wener,

I don't know if there is OpenType/CFF equivalents of the Blue Sky
Research/Y&Y based Computer Modern fonts, but if they exist, you'll want to
check them out.  They use the div operator (which isn't really that exotic,
it's in the Type 1 spec and is used in the Type 1 flavor of the above
fonts).

I suppose I could download the OpenType FDK from Adone and convert the
BSR/Y&Y fonts that can be downloaded from the AMS.

Tom


On Mon, Mar 11, 2013 at 3:30 PM, Werner LEMBERG  wrote:

>
> Folks,
>
>
> the Type 2 specification
>
>   http://partners.adobe.com/public/developer/en/font/5177.Type2.pdf
>
> has a list of `exotic' opcodes which have been mainly added to the
> standard for round-trip conversion of MultipleMaster fonts, a
> technology which is defunct already since more than ten years.  Most
> of the two-byte opcodes belong into this category:
>
>   and, or, not
>   abs,
>   add, sub, div, mul,
>   neg, sqrt
>   eq,
>   drop,
>   put, get
>   ifelse,
>   random,
>   dup, exch, index, roll
>
> I now wonder whether people have CFF fonts (most probably embedded
> into old PDF documents) which actually use those opcodes.
>
> Please report if you have!  I would like to collect use-cases and test
> fonts.
>
>
>  Werner
>
>
> PS: I *do* have fonts which use the deprecated `seac' emulation, so
> this special feature of the `endchar' opcode is not part of my
> request.
>
> ___
> 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] bootstrapping from git source

[Tom Kacvinsky]

Thanks.  Obviously, I missed that.

Tom


On Sun, Feb 17, 2013 at 9:23 PM, Alexei Podtelezhnikov
wrote:

> On Sun, Feb 17, 2013 at 12:20 PM, Tom Kacvinsky 
> wrote:
> > I think the docs are a little out of date with respect to bootstrapping
> > FreeType builds from git source.  I need to get autoconf, automake, and
> > libtool built on Mac OS X before I could run autogen.sh.  The docs as
> far I
> > as could tell only refer to autoconf.
>
> Quoting from docs/INSTALL.UNIX, which is redirected to from
> INSTALL.MAC for OS X:
>
> In case of problems, you  may need to install or upgrade Automake,
> Autoconf or  Libtool.  See  README.git in the  top-level directory
> for more information.
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] bootstrapping from git source

[Tom Kacvinsky]

I think the docs are a little out of date with respect to bootstrapping
FreeType builds from git source.  I need to get autoconf, automake, and
libtool built on Mac OS X before I could run autogen.sh.  The docs as far I
as could tell only refer to autoconf.

Tom
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Greetings

[Tom Kacvinsky]

Howdy all!

I know I said a while ago that I was back to FreeType development, but then
I dropped it.  This time I think it is going to stick.  I need to get into
font programming again.  I've been working on finite element analysis
software for the last eight years as a build support specialist, touching
on Perl, Python, C, C++, assembly, Fortran, custom XML based build tools,
math libraries, some code architecture, etc...  But it's just not the same
as fonts and straight up C programming.

I can work on Linux and Mac OS systems.  Is there an Xcode project for
FreeType, or is it basically still configure driven?

I look forward to contributing again.  I don't know if there is any font
parsing work that needs to be done.  That's what I did before, perhaps I
can get back into that...

Tom
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] freetype.com

[Tom Kacvinsky]

I missed Behdad's solution.  Not sure if freetype-devel got CCed on  
his response.


On 2010/02/24, at 01:04 , Werner LEMBERG wrote:




I vote for a professional letter to them, and if that doesn't work,
use slashdot...


Yeah, sounds reasonable.  However, my English is probably not
`professional' enough to write such a letter.  Behdad proposed a
sensible solution...


Werner




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] freetype.com

[Tom Kacvinsky]

I vote for a professional letter to them, and if that doesn't work,  
use slashdot...


On 2010/02/23, at 20:39 , Werner LEMBERG wrote:




Stumbled upon freetype.com by accident.  Have people seen this
before?  Interesting...


Despicable domain squatting and negative advertising. Shame on them.


Indeed!  I've seen this the first time, and it seems that FreeType is
a threat to them, especially since their `iType' product has the same
target market: embedded devices.

I think we should react, but how?  Contacting them directly?  Telling
the slashdot.org people?  Any other ideas?


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] sfnt version 0x00020000UL

[Tom Kacvinsky]

I recall there being a few fonts from Apple that one could get if  
they installed a foreign language
kit.  It was either the Japanese or Korean kit that had these.  But  
these were back in the Mac OS

9 (and earlier) days.

On 2009/10/11, at 12:40 , Werner LEMBERG wrote:



I noted in the FreeType sources (src/sfnt/sfobjs.c) this check on  
the

version parameter:

if ( tag != 0x0001UL &&
 tag != TTAG_ttcf&&
 tag != TTAG_OTTO&&
 tag != TTAG_true&&
 tag != TTAG_typ1&&
 tag != 0x0002UL )

You can also find sfnts with tag: 'CID '


Hmm.  Does this work with FreeType?  Do you have a sample font?


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] questions about OpenType fonts with CFF data

[Tom Kacvinsky]

http://www.adobe.com/devnet/font/pdfs/5176.CFF.pdf  should give you  
more information on CFF.


AS for your assumptions:

(1) Most OpenTpe/CFF fonts I have seen have only one font in the FontSet

(2) There are other font encoding methods that can be used besides  
CID keyed fonts


(3) I've never seen a CFF font that uses Type 1 charstrings.  So you  
are left with Type 2

  charstrings.

Regards,

Tom


On 2009/10/03, at 12:57 , Manlio Perillo wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

I'm writing an OpenType font parser (in Python), and I want to  
implement

support for parsing the CFF data (I found the parser code in FreeType
very useful, thanks).

Unfortunately the OpenType spec is not very detailed about CFF, so I
have decided to ask the questions here; I hope its not a problem!

I have 3 questions:
1) Should I assume that only 1 font is allowed in the FontSet?
2) Should I assume that only CID-keyed fonts are allowed?
3) Should I assume that only charstring type 2 format is allowed?



Thanks   Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrHgnYACgkQscQJ24LbaUSv6ACeO5YIUxDE6+nUiuqND0+Ipyyh
YAwAn3b2PIfUKbkEDE576CVh1aCDepsa
=M47m
-END PGP SIGNATURE-


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Two questions about TT and TTX

[Tom Kacvinsky]

I  thought TTX was Just's thing, unless something has changed over  
the years...


Tom

On 2009/06/17, at 16:33 , FontGuy wrote:



Hope this isn't too far afield from FreeType topic:

Doing a little noodling with fonts, I see two funny things that  
happen when

you send a font through TTX and back out:

(1):  TTX seems to set bit 1 of the FLAGS in the  section.

! 
! 


TTX changes a bit in the FLAGS field of the header, specifically  
bit 1, the

penultimate LSB.

The official definition in
http://developer.apple.com/textfonts/TTRefMan/RM06/Chap6head.html
   Says:

   ” If bit 1 is set to one, the x-position of the leftmost black  
bit is

assumed to be the left side bearing. “

Any idea what this means?   The font does have left side bearing  
values,

always equal to the xMin value.


-

(2)  Similarly:

! 
! 

Quoting from: developer.apple.com/textfonts/ttrefman/rm06/ 
Chap6maxp.html:


 The maxComponentDepth refers to the number of levels of recursion  
used in

constructing the most complex compound glyph.
In TrueType 1.0, the maximum legal value for maxComponentDepth is one.
 If there are no components within components, all compound glyphs  
can be

deemed simple and this field can be set to the value one.

---

I assume this means that Depth=0 is illogical, as you always need  
at least

one level of definition, and so TTX is just “improving” this value.


Any hints, references, or complaints appreciated.




--
View this message in context: http://www.nabble.com/Two-questions- 
about-TT-and-TTX-tp24081516p24081516.html

Sent from the Freetype - Dev mailing list archive at Nabble.com.



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] git

[Tom Kacvinsky]

Ralph,

Long time, no talk...  How are you?

Thanks, the latter page is what I was looking for.

Tom
 
On Thursday, May 21, 2009, at 11:01AM, "Ralph Giles"  
wrote:
>On Thu, May 21, 2009 at 4:43 PM, Tom Kacvinsky  wrote:
>
>> I am looking at getting back into the FreeType project after a five or so
>> year hiatus.  I see
>> things have moved from cvs to git (skipped svn?)  Does anyone know of a good
>> tutorial on git?
>
>http://git.or.cz/course/svn.html (<-- git in terms of svn)
>http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
>
> -r
>
>


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] git

[Tom Kacvinsky]

Hi,

I am looking at getting back into the FreeType project after a five  
or so year hiatus.  I see
things have moved from cvs to git (skipped svn?)  Does anyone know of  
a good tutorial

on git?

Tom


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] multithreading and 64 bits

[Tom Kacvinsky]

The long integer type on Windows 64 is 4 bytes wide, not 8 bytes wide.
Thank you, MS!  You will have to use ptrdiff_t if you want a full 8 byte
wide integer type.  Werner, I have not looked at the code recently, but
I assume FT_PtrDist is like ptrdiff_t.

Tom

Werner LEMBERG wrote:

Sorry for the late reply.


i am using FreeType library on Windows 64 bits OS Opteron, with a 64
bits executable (FreeType Build in 64 bits).  There is a lot of
problems :
 
On Windows 64 bits, a "FT_Long", or a "Long" ,it's 2 Giga.
 
But when we do a "pointer difference", i can see that a FT_Long is

too small...


You are completely right.

Example : 
 
static void  shift_elements( PS_Table  table,FT_Byte*  old_base )


This particular function I've just fixed in the CVS, thanks (we use
`FT_PtrDist').  Does your compiler generate warnings for other such
situations?  Can you send a compiler log file to this list (possibly
compressed in case it is big)?


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Outline dumper for windows

[Tom Kacvinsky]

> Werner knew this. I don't know how he knew though :-)

Using FontForge to single-step through the bytecode instructions!
This makes great fun (and drives George crazy because of my many bug
reports and feature suggestions).



Werner is good at that kind of stuff. :-)  And I did not know that
FontForge now had TT byte code stepping.  Sweet!

Tom


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel