Re: [Devel] 2.1.0 branch created

[David Turner]

Hi Werner,

Werner LEMBERG a écrit :
> 
> I really hope that the development branch is the head branch (i.e.,
> checking out without specifying a tag I get the current development
> version)!  So you should have created a `stable' branch.  Otherwise,
> please fix this -- it is common behaviour (e.g. Emacs) to do so.
>
Humm.. it seems I goofed here :o) I propose the following, please
tell me if this is correct:

  - create a new branch from the current HEAD, called
    "STABLE-2-0-6"

  - get rid of "VER-2-1-0"

would this be enough ??


> >   I'm currently wondering wether all these changes can fit
> >   adequately in the 2.x release branch, or if we'd better start
> >   working on FreeType 3.x right now.
> 
> Incrementally adding features (if possible) helps to reduce the
> number of bugs :-)
>
Yes, but the internal re-design I have in mind is also quite
drastic and will introduce its own bugs, so I was just wondering
if we didn't better start 3.0 directly..

This would also help debug the MLib earlier, which would be a good
way to speed up the development of UniType (an upcoming font
configuration database library)


> >      - rewriting the library in C++, though I'm uncertain wether
> >        this will be a good thing or not, I'd like your opinion on
> >        the subject. (Of course this doesnt prevent us from providing
> >        a C interface for it)
> 
> Please don't.  Since one of our targets is the embedded market, C
> code is vital IMHO -- maybe I'm wrong, but I doubt that there are a
> lot of C++ compilers out there for such systems.
>
Well, g++ is getting better everyday and can be used on a lot of boards
today. There is also "cfont" and "Comeau C++" which will convert C++ code
to standard C.

However, the problem is that, to be really portable for the
embedded market, we need to ignore the following C++ features:

  - the STL
  - exceptions (at least C++ one, we could use Cleanup-Stack based
    exceptions in C++ though)

So, we'd be left with "C with classes" plus a few extras like
inlining, etc.. I periodically receive e-mail from people who argue
that rewriting the library in C++ would help make its design better.
Someone also wrote me that "the project losed several man-years"
for not choosing C++.. but that's probably a tad extreme point of
view ;-)

I tend to think that OOP is a good way to design code. You can do
it with C, however the resulting code is generally more verbose and
less clear than the corresponding C++ one..

I also agree that the library's current design is sub-optimal, but
that mainly because its features grew out of constant new needs..


So the question really boils down to:

  A - is there enough interest in a C++ version of the library
      (and more especially a C++ native API)

  B - would doing so drastically reduce our development time
      (man-years ??)


Now, my personal opinion on B is that most of the hard work that
has been done in FreeType by your little *me* has nearly nothing to
do with object-orientation. I mean that designing stuff like:

  - the monochrome and anti-aliased rasterizers
  - the TrueType bytecode interpreters
  - various font file table parsers
  - the auto-hinter
  - the Postscript hinter

didn't require any OOP thinking, really. Of course, it's possible
to make some of these elements better now through OOP (the
rasterizers come to mind), but it's a convenience point,
not an important change for something so low-level..

I wouldn't have a problem with switching to C++ if there is
enough demand, I just don't want to do it for the wrong reasons..

So please, people on this list, tell me your answers on A and B !!



> >      - use the MLib, which now supports 95% of the non-font
> >        specific features of FreeType (memory management,
> >        streams, structure i/o, debugging, etc..) as well as
> >        allow for the coding of much simpler and maintainable
> >        code (for more details on this topic, head to
> >        http://www.freetype.org/david/reliable-c.html";)
> 
> Yes!
>
To make another clarification, the two proposals (C++ or MLib) only
concern FreeType 3.x. As much as I'd like to be able to do it right
now, it is not possible to use the MLib within the FreeType 2.x
branch without breaking source and binary compatibility.

That's mainly because the implementation of "FT_Stream" and "FT_Memory"
are not compatible with those of "M_Stream" and "M_Memory". There are
a few other subtle reasons that I won't detail there, but we simply
can't use it in the 2.x family..

Same goes for C++ of course :-)

There is also the point that some of the new features that are going
to be introduced in the 2.1.x branch are not font-specific and could
be developed in the MLib instead (and be a lot simpler to code and use
as well). I'm thinking about the new module/service management, which
will be a simplified version of the KoreLib (a C++ framework, see:
http://http://www.thekompany.com/projects/korelib/design.php3)

implementing once in FT2, then rewriting it in the MLib would be a
pain..

 
> >   Meanwhile, I intend to work on the 'jam' build tool. My first goal
> >   is to support Unix builds and installation flawlessly for FreeType
> >   in order to get rid of our infamous Make-based build system. I
> >   also want to collaborate with the Boost project (www.boost.org)
> >   since they have enhanced Jam to support really interesting things
> >   like the management of multiple builds (debug/release/optimized)
> >   (with all the voodoo that it requires, like determining special
> >   compilation options, etc..)
> 
> What annoys me most is that there is no maintainer of jam.  So many
> people are doing so many changes in parallel.  I really hope this can
> be fixed somehow (e.g. integrating your changes into the boost
> system).
>
Here are some important facts about Jam:

  - it seems that Perforce has finally awaken and is going to release
    a new version of Jam pretty soon (next week ??). This one will include
    some improvements made by third-party, and I hope that some of mine
    will be in.

    This would mean that we could use the standard Jam tool, instead of
    having to maintain our own.. Which is a very good thing..


  - The Boost project has taken "ftjam" and enhanced it considerably to
    provide many extremely powerful capabilities. The resulting program
    is called "Boost.Jam" for now (I know, it's not an easy name, I
    personnaly nick-name it "jambo").

    Boost.Jam is built on top of Jam but brings a lot more. The end results
    is that the resulting control files have a slightly different syntax
    than regular Jamfiles, but can do much more.. You could really compare
    that to the differences between TeX and LaTeX. Each one of them
    provides a different set of rules/macros while using the same basic
    engine..

    In all cases, both tools blow Make and its ilk away, and are Autoconf
    compatible ;-)

    I intend to cooperate with the Boost.Jam team, since Perforce seems to
    be extremely conservative about the original Jam source (and they have
    very good reasons for that).. This team is also a lot more structured,
    opened and active, which means that I don't fear spurious forks of
    their sources..

 
> > So little things to do, so little time :o)
> 
> You mean `so many things', don't you :-)
>
No, it's exactly what I meant, since it was just a joke :-)

Regards,

- David