[SharpOS Developers] Freetype

[colin...@daimler.com]

Hi guys,

I'm new here so I don't know the status of the project too well. Have any of you tried to compile Freetype to MSIL? I've spent a couple of hours and had some amount of success.

I don't know what to do about the calls to setjmpor longjmpso I've just dummied those out. After that I get about 15 unresolved externals that I'm struggling with. Its been a while since I looked at c++, I've been a c# man for a number of years now. Would anybody be interested in looking at what I have so far?

Cheers

Colin
If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation.

[grover]

Hi Colin,

Sure. We're always interested in help. I suppose what you're seeing are
imports from the C runtime library. As we don't have one there needs to be a
replacement of some sort there though.

Mike

> -----Ursprüngliche Nachricht-----
> Von: colin...@daimler.com [mailto:colin...@daimler.com]
> Gesendet: Montag, 22. September 2008 21:56
> An: sharpos-d...@lists.sourceforge.net
> Betreff: [SharpOS Developers] Freetype

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-D...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers

[Maciej Jagiello]

If we get it to compile targeting cli:pure we can try decompiling it to
c#, so it could be of some help in porting. But I fear it won't work too
well...
Btw the FreeType's license is original-with-advertising-clause-BSD-like
(GPL incompatible) dual-licensed with GPLv2 (Linux someone? ;)). Is it
possible to apply our GPL w/ CPE if we port it?
Anyway, I have started TrueType loading. I attached what I have so far
as archive if you want to take a look or continue working on it. Note
there's no license header attached yet and there's some code from a Java
LGPLed TTF editor in it! I can identify those parts later on if needed.

ps. Apple's patents for ttf hinting are expiring in a year, am I wrong?
What a complicated world we live in, mattaku... :D

> ------------------------------------------------------------------------

>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/

> ------------------------------------------------------------------------

[grover]

Hi Maciej,

If we can target cli:pure, we could as well use the original
sources for the time being.

Thanks for the patent info, but what about the OpenType patents
Adobe holds? I believe OpenType/TrueType are close in definition?

Mike

> -----Ursprüngliche Nachricht-----
> Von: Maciej Jagiello [mailto:hime...@o2.pl]
> Gesendet: Montag, 22. September 2008 23:49
> An: sharpos-d...@lists.sourceforge.net
> Betreff: Re: [SharpOS Developers] Freetype

> > --- This SF.Net email is sponsored by the Moblin Your Move

[colin...@daimler.com]

Actually these are things that Freetype define. Take a look...

1>ftinit.obj : error LNK2020: unresolved token (0A00000F) t1cid_driver_class
1>ftinit.obj : error LNK2020: unresolved token (0A000010) tt_driver_class
1>ftinit.obj : error LNK2020: unresolved token (0A000013) bdf_driver_class
1>ftinit.obj : error LNK2020: unresolved token (0A000015) ft_smooth_lcdv_renderer_class
1>ftinit.obj : error LNK2020: unresolved token (0A00001D) t1_driver_class
1>ftinit.obj : error LNK2020: unresolved token (0A00001F) pcf_driver_class
1>ftinit.obj : error LNK2020: unresolved token (0A000020) ft_smooth_renderer_class
1>ftinit.obj : error LNK2020: unresolved token (0A000021) ft_smooth_lcd_renderer_class
1>ftinit.obj : error LNK2020: unresolved token (0A000027) pfr_driver_class
1>ftinit.obj : error LNK2020: unresolved token (0A00002A) ft_raster1_renderer_class
1>ftinit.obj : error LNK2020: unresolved token (0A00002F) cff_driver_class
1>ftinit.obj : error LNK2020: unresolved token (0A000033) t42_driver_class
1>ftinit.obj : error LNK2020: unresolved token (0A000034) winfnt_driver_class
1>ftstroke.obj : error LNK2001: unresolved external symbol "struct FT_Glyph_Class_ const ft_outline_glyph_class" (?ft_outline_glyph_class@@$$Q3UFT_Glyph_Class_@@B)
1>.\..\..\..\objs\debug_mt\freetype.dll : fatal error LNK1120: 14 unresolved externals

Unfortunately my C++ skills are rusty to say the least. I don't see what is different between these "tokens" that are not compiling and those that are.

Colin

sha...@michaelruck.de 09/22/2008 01:35 PM Please respond to sharpos-d...@lists.sourceforge.net

To sharpos-d...@lists.sourceforge.net cc Subject Re: [SharpOS Developers] Freetype

[colin...@daimler.com]

Is there any reason why you prefer C# over managed C++?

sha...@michaelruck.de 09/22/2008 02:52 PM

Please respond to sharpos-d...@lists.sourceforge.net

To sharpos-d...@lists.sourceforge.net cc Subject Re: [SharpOS Developers] Freetype

[grover]

It is just a preference. C# is the language of choice for .NET and I'd say
most .NET devs are familiar with C#. Maintaining a C++/CLI project is
possible, but not everyone is capable of doing so. Finally some of us do not
want to reuse legacy code...

Mike

> -----Ursprüngliche Nachricht-----
> Von: colin...@daimler.com [mailto:colin...@daimler.com]

> Gesendet: Dienstag, 23. September 2008 00:00
> An: sharpos-d...@lists.sourceforge.net
> Cc: sharpos-d...@lists.sourceforge.net

[Chad Z. Hower aka Kudzu]

> It is just a preference. C# is the language of choice for .NET and I'd

While I prefer C#, and I find most Senior devs too, VB.NET accounts for
about 65% of .NET development.....

[Jonathan Dickinson]

I don't have time to hash out a long email now but I have been working on porting freetype to c#.

I am going to run it off system.drawing so that it will drop in when that is complete.

Quick status: started decoding the instructions, reminds me of msil decoding :), albiet horrific documentation.

I don't think anyone would be too hot on just compiling freetype as is, it wasn't architected with the .net paradigms/practices/styles in mind. It will be like using mogre (anyone used it? it hurts to write code like that).

Not to mention [I assume] most of the coders around here don't use c++ that much :). I will see about dropping my code in a repo when it gets a bit more feature complete.

Email me direct if you want a zip of what I have so far.

---

From: colin...@daimler.com
Sent: 22 September 2008 09:55 PM
To: sharpos-d...@lists.sourceforge.net
Subject: [SharpOS Developers] Freetype

[Colin Burn]

I would be interested in knowing how complete or incomplete this is. I agree that a complete rewrite would be a better idea, I'm just surprised that somebody is actually attempting it.

---

From: jonath...@gmail.com
Date: Tue, 23 Sep 2008 20:57:55 +0200
To: sharpos-d...@lists.sourceforge.net

Subject: Re: [SharpOS Developers] Freetype

---

Get more out of the Web. Learn 10 hidden secrets of Windows Live. Learn Now

[Jonathan Dickinson]

Okay, I will have some free time this weekend and I will attempt to get all the vm instructions decoded. Right now its more architectural than anything else, but I am making fast progress. I have most of the important tables decoded.

I am going to dodge the obvious things like hinting etc. for now, and hopefully someone with typography experience joins later on.

I am really hoping I will have something working on top of system.drawing by monday, even if its doesn't come out just right.

This weekend is going to be busy :).

---

From: Colin Burn <coli...@hotmail.com>
Sent: 24 September 2008 03:59 PM

To: sharpos-d...@lists.sourceforge.net
Subject: Re: [SharpOS Developers] Freetype

I would be interested in knowing how complete or incomplete this is. I agree that a complete rewrite would be a better idea, I'm just surprised that somebody is actually attempting it.

---

From: jonath...@gmail.com
Date: Tue, 23 Sep 2008 20:57:55 +0200
To: sharpos-d...@lists.sourceforge.net
Subject: Re: [SharpOS Developers] Freetype

I don't have time to hash out a long email now but I have been working on porting freetype to c#.

I am going to run it off system.drawing so that it will drop in when that is complete.

Quick status: started decoding the instructions, reminds me of msil decoding :), albiet horrific documentation.

I don't think anyone would be too hot on just compiling freetype as is, it wasn't architected with the .net paradigms/practices/styles in mind. It will be like using mogre (anyone used it? it hurts to write code like that).

Not to mention [I assume] most of the coders around here don't use c++ that much :). I will see about dropping my code in a repo when it gets a bit more feature complete.

Email me direct if you want a zip of what I have so far.

---

From: colin...@daimler.com
Sent: 22 September 2008 09:55 PM

[The entire original message is not included]

[Sander van Rossen]

You know, i think eventually we should translate truetype directly to
msil (and JIT compile it when we're able to).. should be good
performance wise

[Jonathan Dickinson]

I also reached that stage a while back. Unfortunately, it seems as though the best method is caching the glyphs. Wpf and windows do that, and I would assume freetype and the linux libraries do that as well.

Although... When it comes to fitting and hinting I don't think cached glyphs could be used as-is. Hmmm. Sounds like fun, maybe I will have a crack at it. The benefits of machine execution probably outweigh the benefits of caching by a lot, especially when it comes to memory usage. Tweaking existing paths is also probably expensive.

You could generate the ttf assembly when the ttf is 'installed', and be over with ttf monstrosities (those guys belong in a zoo where we can feed them true type bananas). Different font codecs (opentype, bitmap FONs, etc) would simply take an input stream and provide an assembly that implements well known interfaces.

Thanks for iterating that thought process again Sander! Ttf is fun once again!

-----Original Message-----
From: Sander van Rossen <s.v.r...@synthesis.nl>
Sent: 25 September 2008 09:16 AM
To: sharpos-d...@lists.sourceforge.net
Subject: Re: [SharpOS Developers] Freetype