Re: [ft-devel] Getting Module Pointer From a Module Function?
Hi Mickey, 2009/1/22 Mickey Gabel mic...@monfort.co.il Is there a standard/good way to get the module pointer (not the module class, I am talking about FT_ModuleRec that contains the module's data). Case in point: I am working on af_face_globals_new() in autofit/afglobals.c which is part of the autofit module. Is there a way to get to the FT_AutofitterRec which is initialized during module init (AutoFitterRec is defined in autofit/afmodule.c) ? I could add the parameter explicitly, but is there a more standard way? You could try calling FT_Get_Module( face-library, module name ); I'm surprised you'd want to do that though, what kind of non-font-face-specific data would you like to store there ? Are you trying to cache the result of global glyph analysis to speed up things. I would recommend provide a way for the library user to store it in its own cache, with callbacks to lookup/add the data from the font engine. That way the client could control exactly how much memory is consumed by this scheme. Regards - David ___ 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
[ft-devel] Switching to Git ?
Hello everyone, long time no see :-) I'd like to know if Werner and others are interested in switching the FreeType repository to git in the near future ? I've been a heavy user of the tool since several months, and while there are really a few bat-shit insane user-interface issues with it (even in most recent releases), it beats CVS hands down in nearly all respects. I'm currently maintaining my own git repo with git-cvsimport, which works pretty well, but would like the ability to directly talk to the main server that way. Nothing really of high priority, but I wanted at least to know your opinion about it ? Regards - David ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Switching to Git ?
On Mon, Feb 23, 2009 at 10:02 AM, David Turner da...@freetype.org wrote: I'd like to know if Werner and others are interested in switching the FreeType repository to git in the near future ? Hi David! This would be nice for me as well. Nothing really of high priority, but I wanted at least to know your opinion about it ? There was a thread about this in December in January. Suzuki-san did some trial conversions and there was some discussion about editing the commit messages to give a better shortlog as part of an official conversion. http://lists.gnu.org/archive/html/freetype-devel/2008-12/msg00074.html http://lists.gnu.org/archive/html/freetype-devel/2009-01/msg1.html Note that git support on windows is still shaky. -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Switching to Git ?
long time no see :-) Glad that you are still alive. I'd like to know if Werner and others are interested in switching the FreeType repository to git in the near future ? Yes. I will do a new release soon (there are very embarrasing errors w.r.t. FT_Get_Advance which I'l fixing right now), then such a switch would be nice. We've discussed conversion to git earlier; you might look up the devel archive for details. I'm currently maintaining my own git repo with git-cvsimport, which works pretty well, but would like the ability to directly talk to the main server that way. Well, a direct import is trivial; however, it would be beneficial to walk over, say, the last 1000 to 2000 commits so that all get a nice one-line title. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [NECSV - LSB PJ] Freetype documentation issues report V0029
the fact that we use FreeType error code means that we explicitely do not want to list a specific set of codes, or in other words that any error code could be returned. I've already prepared some improvements w.r.t. the documentation of error codes. This should be part of the repository in a not too distant future. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Switching to Git ?
From a purely personal point of view I welcome a move to git, simply to give me an incentive to learn git :-) Graham -Original Message- From: freetype-devel-bounces+graham.asher=btinternet@nongnu.org [mailto:freetype-devel-bounces+graham.asher=btinternet@nongnu.org] On Behalf Of Werner LEMBERG Sent: 23 February 2009 18:26 To: da...@freetype.org Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] Switching to Git ? long time no see :-) Glad that you are still alive. I'd like to know if Werner and others are interested in switching the FreeType repository to git in the near future ? Yes. I will do a new release soon (there are very embarrasing errors w.r.t. FT_Get_Advance which I'l fixing right now), then such a switch would be nice. We've discussed conversion to git earlier; you might look up the devel archive for details. I'm currently maintaining my own git repo with git-cvsimport, which works pretty well, but would like the ability to directly talk to the main server that way. Well, a direct import is trivial; however, it would be beneficial to walk over, say, the last 1000 to 2000 commits so that all get a nice one-line title. 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] Multi-threading question
2009/2/23 Mike Moening mi...@reteksolutions.com In the 2.3.8 documentation it states that each thread should have its own FT_Library object. Currently we keep one FT_Library per FT_Face. We have a C++ wrapper object per font face which wraps these two together. We use FT_New_Memory_Face() to load the face into the object. Because the font files are rather large (several Megabytes) we leave the face open, so as not to re-load it every time we need to get metrics on a different glyph. Question: Can we safely use the stored FT_Face handle with other FT_Library instances? Assuming (per documentation suggestions) that we have a FT_Library per thread. No you can't. The idea is to allow multiple threads to get glyph metrics by simultaneosly calling these methods: FT_Set_Char_Size() FT_Get_Char_Index() FT_Load_Glyph() Once we retreive the metrics we store each set of metrics in map hashed by glyph which is owned by the wrapper object. This map is protected by a lock of course. It seems to me, based on my understanding of the code, that there would be no way to allow each thread to access the metrics unless each thread calls FT_New_Memory_Face() and has its own handle to the face. Exactly. That seems sub-optimal. The eye is in the beholder. Allowing what you want would make the design of FreeType much more complicated and would also make it use more memory in all cases. And if your file is memory-mapped, you shouldn't have much performance degradation from using several FT_Library/FT_Face in parallel anyway; and each thread should go as fast as possible, without any potential for locking or contention. I welcome suggestions on the fastest architecture to simulaneously retrieve font metrics with multiple threads. Thanks, Mike M. ___ 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] Switching to Git ?
On Mon, 2009-02-23 at 19:25 +0100, Werner LEMBERG wrote: Well, a direct import is trivial; however, it would be beneficial to walk over, say, the last 1000 to 2000 commits so that all get a nice one-line title. My 'parsecvs' tool will probably handle freetype's CVS repository fairly well. It's not easy to use, but was used to convert X.org's repositories where other tools failed due to the fairly complex (and often broken) history. It requires direct access to the CVS source repository; if you'd like me to give this a try, let me know. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Switching to Git ?
David Turner wrote: Hello everyone, long time no see :-) I'd like to know if Werner and others are interested in switching the FreeType repository to git in the near future ? That would also make it easier for me to hack on FreeType (the only piece of GNOME-based text rendering stack I've not mastered yet). behdad I've been a heavy user of the tool since several months, and while there are really a few bat-shit insane user-interface issues with it (even in most recent releases), it beats CVS hands down in nearly all respects. I'm currently maintaining my own git repo with git-cvsimport, which works pretty well, but would like the ability to directly talk to the main server that way. Nothing really of high priority, but I wanted at least to know your opinion about it ? Regards - David ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Switching to Git ?
Tad !
An experimental git repository is now in place, see http://git.freetype.org
Note that:
- this was created by taking a snapshot of the current CVS repository;
running git-cvsimport on it then 'git-filter-branch --msg-filter' with the
attached (basic) script to improve the commit messages a bit.
(It's still not perfect, could be improved in the future)
- read-only access :-)
- there is *no* git = CVS bridge at the moment, I'm still trying to get
the exact details on how to properly set this up. There is no point to
provide write access until this is solved.
- this runs on my home Zonbu box behind my DSL router; so don't expect
any kind of scalability at the moment; it's really an experimental setup to
show what's possible in a few hours.
- gitosis / git-daemon / gitweb are nice, but oh my, they are so badly
documented that it's hard to avoid many pitfalls. I'll try to document them
later.
- We will probably want to move this to a real server in the future. For
now consider this as an experiment. I'm probably going to scrap it and start
another one from scratch with a better commit message rewriter. I've given
up rewriting the CVS messages themselves. I will warn before doing so, or
create a different branch.
Comments and opinions welcome.
2009/2/23 Keith Packard kei...@keithp.com
On Mon, 2009-02-23 at 19:25 +0100, Werner LEMBERG wrote:
Well, a direct import is trivial; however, it would be beneficial to
walk over, say, the last 1000 to 2000 commits so that all get a nice
one-line title.
My 'parsecvs' tool will probably handle freetype's CVS repository fairly
well. It's not easy to use, but was used to convert X.org's repositories
where other tools failed due to the fairly complex (and often broken)
history.
It requires direct access to the CVS source repository; if you'd like me
to give this a try, let me know.
--
keith.pack...@intel.com
#!/usr/bin/python
#
# This script is used to convert the FreeType commit messages
# to a simpler one-liner format.
#
# What we want to do here is to essentially replace messages that
# look like the following:
#
#* path1/file1.c (some_function), path2/file2.c,
# path3/file3.c: THE REAL COMMIT MESSAGE THAT CAN
# SPAN SEVERAL LINES
#
# by:
#
#THE REAL COMMIT MESSAGE THAT CAN SPAN SEVERAL LINES
#* path1/file1.c ... : THE REAL COMMIT MESSAGE ... etc
#
# not totally elegant, but gets the job done :-)
#
import sys, os, string, re
lines = []
lineStart = True
lineCurrent =
re_sourcePath = re.compile(r\s*([A-Za-z_][A-Za-z0-9_/.]*)\s*(.*))
re_functionName = re.compile(r\([^)]*\)\s+(.*))
# read lines from stdin and create paragraphs into lines
for line in sys.stdin.readlines():
# strip trailing LN
line = string.strip(line)
if len(line) 0 and line[-1] == '\n':
line=line[:-1]
if len(line) == 0:
if not lineStart:
lineStart = True
lines.append(lineCurrent)
lineCurrent =
else:
if not lineStart:
lineCurrent +=
lineCurrent += line
lineStart= False
if not lineStart:
lines.append(lineCurrent)
# now, check whether the first paragraph begins with an asterisk
lines2=[]
for line in lines[0:1]:
firstLine = line[:]
if firstLine[0] == '*':
# find the location of the column
index = firstLine.rfind(':')
if index 0:
firstLine = string.strip(firstLine[index+1:])
lines2.append(firstLine)
lines2.append(line)
for line in lines2:
print line
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Switching to Git ?
On Mon, Feb 23, 2009 at 6:20 PM, David Turner da...@freetype.org wrote:
An experimental git repository is now in place, see http://git.freetype.org
Woo!
gitosis / git-daemon / gitweb are nice, but oh my, they are so badly
documented that it's hard to avoid many pitfalls. I'll try to document them
later.
No kidding. I've set up a couple of gitweb instances, if you need any help.
In particular:
edit *.git/description to set the description column in the gitweb index
add the git-daemon base url to the git_base_url_list definition in
gitweb.cgi. Something like
our @git_base_url_list = grep { $_ ne '' } (git://git.freetype.org);
There's some way to also list an http url, which is helpful for people
behind firewalls, but I've not figured it out yet. You don't want to
default to the http url because it's so much slower.
-r
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
