Crend King | 1 Oct 08:16 2009
Picon

[ft] Can I send/receive FT_*Rec structs via network or RPC?

Hello friends. Recently I'm trying to build a server hosting the 
FreeType library and cache objects, and clients which request the 
rendered character bitmaps from the server. The advantage of doing this 
is the cache in the server is highly shared and reused, and the clients 
are only in charge of implementing the system-specific text out 
procedures. The problem is, sending/receiving the data via network or 
RPC or pipes requires marshaling or serialization. Since there are so 
many embedded pointers in the FT_*Rec structs, and some of them even 
have private members, how do I fully serializing them? Not only do I 
need the final FT_Bitmap, but also I need many metrics and flags stored 
in FT_Face and FT_Size, etc.

One way to solve this problem is to wrap every client-needed field into 
a RPC function, or network request. When the client implementation gets 
more and more complicated, the RPC interface may become messy, and the 
network protocol would be difficult to maintain. Is there any routine 
way to achieve this? I'm really new to FreeType and IPC. Any help is 
appreciated. Thanks!!
Werner LEMBERG | 1 Oct 17:41 2009
Picon

Re: [ft] Can I send/receive FT_*Rec structs via network or RPC?

> Recently I'm trying to build a server hosting the FreeType library
> and cache objects, and clients which request the rendered character
> bitmaps from the server.  The advantage of doing this is the cache
> in the server is highly shared and reused, and the clients are only
> in charge of implementing the system-specific text out procedures.

I think this only works efficiently if you don't use subpixel
rendering...

> The problem is, sending/receiving the data via network or RPC or
> pipes requires marshaling or serialization.  Since there are so many
> embedded pointers in the FT_*Rec structs, and some of them even have
> private members, how do I fully serializing them?  Not only do I
> need the final FT_Bitmap, but also I need many metrics and flags
> stored in FT_Face and FT_Size, etc.

What you want to do is something FreeType hasn't been designed for.

> One way to solve this problem is to wrap every client-needed field
> into a RPC function, or network request.  When the client
> implementation gets more and more complicated, the RPC interface may
> become messy, and the network protocol would be difficult to
> maintain.  Is there any routine way to achieve this?

I don't think so.

    Werner
Werner LEMBERG | 4 Oct 08:09 2009
Picon

Re: [ft] Defective true type font


> Thanks; Is there a "porting guide" for the demos? I will be porting
> ftview and ftgrid to a small graphics library that isn't
> supported. It has a simple 2D raster type API that I will use to
> render the glyphs (including bitmaps).

You have to port the small `graph' library which is part of the
freetype2-demos bundle; then the rest of the demo programs should link
just fine.  `graph' comes already with support for 6 different OS, so
it shouldn't be too hard to add another one or replace it entirely
with something equivalent.

Note that probably some of the OS support files are no longer
functional; AFAIK, support for Windows and X11 work just fine.

    Werner
Matt Goebel | 6 Oct 23:37 2009

[ft] freetype 2.3.9 and recent security warnings?


Hi,

  I was just wondering if the recent security issues with freetype 
affect 2.3.9, and if so, if there is a new version coming out to
address them?

Thanks,
Matt Goebel

--

-- 
Matthew Goebel : goebel <at> emunix.emich.edu : Unix Jockey  <at>  EMU : Hail Eris
Neo-Student, Net Lurker, Donut consumer, and procrastinating Brewer...
 "Always with the negative waves, Moriarty" - Oddball
 "Comfort the troubled, and trouble the comfortable." - Dietrich Bonhoeffer
mpsuzuki | 8 Oct 06:18 2009
Picon

Re: [ft] freetype 2.3.9 and recent security warnings?

Hi,

On Tue, 6 Oct 2009 17:37:01 -0400 (EDT)
Matt Goebel <goebel <at> emunix.emich.edu> wrote:
>  I was just wondering if the recent security issues with freetype 
>affect 2.3.9, and if so, if there is a new version coming out to
>address them?

Thank you for question about the security issue.

I think most issues are fixed in git, if they
were reported to us with patches. But there might
be "open" issues that were reported without patch,
platform-specific that we could not reproduce, or
not reported to us.

I had better post a summary about the status of
the security issues. Could you recommend some longest
list of FreeType security issues?

Regards,
mpsuzuki
Werner LEMBERG | 8 Oct 07:29 2009
Picon

Re: [ft] freetype 2.3.9 and recent security warnings?

>>  I was just wondering if the recent security issues with freetype 
>>affect 2.3.9, and if so, if there is a new version coming out to
>>address them?
> 
> Thank you for question about the security issue.
> 
> I think most issues are fixed in git, if they
> were reported to us with patches. But there might
> be "open" issues that were reported without patch,
> platform-specific that we could not reproduce, or
> not reported to us.

Freetype 2.3.10 has been already uploaded but not announced yet.  This
follows in a few hours.

    Werner
Massimo DZ8 | 8 Oct 10:54 2009
Picon

[ft] 2.3.10?

Greetings everyone, I have just downloaded Freetype and signed to the list.

I noticed that on freetype.org the latest version seems to be 2.3.9 
(March 2009), yet on the download area I can find a 2.3.10 (October 2009).
I wonder if the admin just forgot to update freetype.org or there's a 
reason for that. Looking at the changelog, it seems that .10 packs 
mostly internal updates and improvements transparent to me (I will be a 
mere library user). Is this correct?

Have a nice day,
Massimo
Werner LEMBERG | 8 Oct 11:18 2009
Picon

Re: [ft] 2.3.10?


> I noticed that on freetype.org the latest version seems to be 2.3.9
> (March 2009), yet on the download area I can find a 2.3.10 (October
> 2009).
> I wonder if the admin just forgot to update freetype.org or there's a
> reason for that.  [...]

I'm updating everything right now.

    Werner
Werner LEMBERG | 8 Oct 11:20 2009
Picon

[ft-devel] FreeType version 2.3.10 has been released


FreeType 2.3.10 has been released.

It is available from

    http://savannah.nongnu.org/download/freetype/

or

    http://sourceforge.net/project/showfiles.php?group_id=3157

The latter site also holds older versions of the FreeType library.

See below  for the  relevant snippet  from the  CHANGES file; users of
version 2.3.9 should upgrade.

Enjoy!

   Werner

----------------------------------------------------------------------

FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
producing high-quality output (glyph images) of most vector and bitmap
font formats.

Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
perform higher-level features, like text layout or graphics processing
(e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it
(Continue reading)

Gabriele Brugnoni | 7 Oct 18:38 2009
Picon

[ft] Internal interface patch for sdl-freetype library

Hi,

Referring to the page
http://www.freetype.org/freetype2/freetype-2.2.0.html I send this
patch hoping it might be useful to others.

This patch fix the problem below that may happen when building
sdl-freetype library with newer version of freetype:

In file included from SDL_freetype.c:12:
SDL_freetypeutils.h:17:38: error: freetype/internal/ftobjs.h: No such
file or directory

Regards,
Gabriele Brugnoni.

This is the patch:

diff -ubBrN sdl-freetype-1.0.0-org/src/SDL_freetypeloader.c
sdl-freetype-1.0.0-mdf/src/SDL_freetypeloader.c
--- sdl-freetype-1.0.0-org/src/SDL_freetypeloader.c 2009-10-07
17:46:08.000000000 +0200
+++ sdl-freetype-1.0.0-mdf/src/SDL_freetypeloader.c 2009-10-07
17:46:49.000000000 +0200
 <at>  <at>  -58,7 +58,7  <at>  <at> 
stream->read = SDL_FreeTypeRead;
stream->close = SDL_FreeTypeClose;
stream->descriptor.pointer = RWops;
- stream->memory = SDL_FreeTypeLibrary->memory;
+ stream->memory = NULL;//SDL_FreeTypeLibrary->memory;
(Continue reading)


Gmane