Hi, Here's a first version of an sfd2ttf tool based on fontforge-20051205. You can dwonload it from [1]. It consists of 5 files (with Makefile) and has a size of 500K. There's still some dead code lying around, I think I can bring it down to 300K-400K. Is this acceptable? SFD reading was quite easy, the code was well seperated. TTF generation was a bit harder. I decided to output TrueType, with bitmap tables from OpenType. The others ttf variations (full OpenType or even aat (Apple Advanced Typography)) are not supported, as it would make the tool a lot bigger (factor 2-5 or so) and i believe it's not needed (right?). I'm really no font expert, so any comment is welcome. Markus [1] http://oribi.org/download/sfd2ttf.tar.gz
Markus Amsler wrote:
Here's a first version of an sfd2ttf tool based on fontforge-20051205. You can dwonload it from [1].
Great work!
It consists of 5 files (with Makefile) and has a size of 500K. There's still some dead code lying around, I think I can bring it down to 300K-400K. Is this acceptable?
I think it should be, and will help you to bring it in line with Alexandre's wishes where possible. He's on holiday in Greece at the moment, so you might have a to wait a bit for his comments.
TTF generation was a bit harder. I decided to output TrueType, with bitmap tables from OpenType. The others ttf variations (full OpenType or even aat (Apple Advanced Typography)) are not supported, as it would make the tool a lot bigger (factor 2-5 or so) and i believe it's not needed (right?).
I'm really no font expert, so any comment is welcome.
Seems reasonable, but I'm not a font expert either. Mike
"Markus Amsler" <markus.amsler(a)oribi.org> wrote:
Here's a first version of an sfd2ttf tool based on fontforge-20051205. You can dwonload it from [1].
Did you run 'make test' in the dlls/gdi directory to see that font metrics of the generated bitmap fonts match the windows ones? fontforge earlier than beginning of 2006 had a bug which led to wrong bitmap font metrics, so you may consider to use more recent sources.
It consists of 5 files (with Makefile) and has a size of 500K. There's still some dead code lying around, I think I can bring it down to 300K-400K. Is this acceptable?
IMHO that's too much. Even 100K would be.
SFD reading was quite easy, the code was well seperated. TTF generation was a bit harder. I decided to output TrueType, with bitmap tables from OpenType. The others ttf variations (full OpenType or even aat (Apple Advanced Typography)) are not supported, as it would make the tool a lot bigger (factor 2-5 or so) and i believe it's not needed (right?).
Did you test that .ttf fonts generated with your tool are properly handled by freetype and Wine's sfnt2fnt? -- Dmitry.
On Fri, 2006-04-28 at 18:46 +0900, Dmitry Timoshkov wrote:
It consists of 5 files (with Makefile) and has a size of 500K. There's still some dead code lying around, I think I can bring it down to 300K-400K. Is this acceptable?
IMHO that's too much. Even 100K would be.
I agree, this is a _lot_ of code for what? It's not like we can make heads or tails of the diffs for fonts anyway. I agree that is good not to have binary files in CVS, but these are binary files that are cross platform, need not be rebuild by users, etc. We are paying a hefty price for this -- only the discussions up to this point counted for probably tens of precious developer hours, not to mention the hundred of hours of user frustration. In fact, these 'noarch' binary files in CVS are not such a big deal. It turns out that every Java project is checking in 3rd party jars without one single negative side effect. Font files are just like .jar files. Lets just commit them and be done with it. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
IMHO that's too much. Even 100K would be.
I agree, this is a _lot_ of code for what? It's not like we can make heads or tails of the diffs for fonts anyway. I agree that is good not to have binary files in CVS, but these are binary files that are cross platform, need not be rebuild by users, etc.
We are paying a hefty price for this -- only the discussions up to this point counted for probably tens of precious developer hours, not to mention the hundred of hours of user frustration.
In fact, these 'noarch' binary files in CVS are not such a big deal. It turns out that every Java project is checking in 3rd party jars without one single negative side effect. Font files are just like .jar files. Lets just commit them and be done with it.
Nice to hear another voice of reason in all this mess. I hope that sfd2ttf and all the related *#$%!@ will be gone from wine as soon as possible. I don't think that wine should depend on fontforge either. If and when necessary, the ttfs can be regenerated by hand and checked in by whomever changed the sfds. All it takes is a small readme file in the directory where the sfds are, to describe the necessary steps and prerequisites. Heck, you can even have a tiny handwritten makefile in there. Cheers, Kuba
Kuba Ober wrote:
IMHO that's too much. Even 100K would be.
I agree, this is a _lot_ of code for what? It's not like we can make heads or tails of the diffs for fonts anyway. I agree that is good not to have binary files in CVS, but these are binary files that are cross platform, need not be rebuild by users, etc.
Nice to hear another voice of reason in all this mess. I hope that sfd2ttf and all the related *#$%!@ will be gone from wine as soon as possible.
Somebody has finally spent the time needed to: 1) Eliminate a dependency (good!) 2) Keep binaries out of the GIT/CVS tree (good!) 3) (Hopefully) keep Alexandre happy in the process. (good!) The code is still a bit big, but I'm confident that can be addressed. If binaries were going into the source tree, then it would have started with the icon/bitmap resource. Anybody remember who spent "tens of precious developer hours" to come up with bin2res so we didn't need to checkin binaries then? Mike bash-3.00$ grep Kuba ChangeLog | wc 0 0 0 bash-3.00$ head -6 tools/bin2res.c /************************************************ * * Converting binary resources from/to *.rc files * * Copyright 1999 Juergen Schmied * Copyright 2003 Dimitrie O. Paun
On Fri, April 28, 2006 9:42 am, Mike McCormack said:
Somebody has finally spent the time needed to: 1) Eliminate a dependency (good!)
This is indeed a problem and it would eliminated in both cases. It's just a matter of how we accomplish this.
2) Keep binaries out of the GIT/CVS tree (good!)
I'm all for this, don't get me wrong. But it is not an absolute thing, it has to be balanced against the other evil. If we blindingly follow that it is just dogma, and it doesn't seem to be such a worthy cause after all. As I said, virtually any Java project in existance checks in .jar files, and none of them suffer from any negative ill effect.
The code is still a bit big, but I'm confident that can be addressed.
It's insanely big. And it's not a one time thing, we'll have to maintain that. It's an ongoing cost. With what purpose? We will still have the textual representation in GIT, so changes will be displayed for those so inclined to read them. The binary files will not be included in the diffs. Bottom line is that from an outside perspective the diffs will not change. The only thing that will change is: 1. No dep on fontforge 2. Ability to control _which_ fontforge we use 3. Uniformity in fonts used by users (easier to support, etc) 4. Simplicity What we loose is just an increased size of the archive. How big will this increase be, BTW? Can someone please how big is a .tar.bz2 of all the binary font files?
If binaries were going into the source tree, then it would have started with the icon/bitmap resource. Anybody remember who spent "tens of precious developer hours" to come up with bin2res so we didn't need to checkin binaries then?
Please, that's a trivial utility. As I said, it's a balancing act. It was very simple to have the bin2res, it looks a lot more complicated to have sfd2ttf. If all we wanted is to avoid binaries in GIT (why?), we can covert .ttf to hex via bin2res :) But I think that would be worse than the problem... -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
On Friday 28 April 2006 16:22, Dimi Paun wrote:
Please, that's a trivial utility. As I said, it's a balancing act. It was very simple to have the bin2res, it looks a lot more complicated to have sfd2ttf. If all we wanted is to avoid binaries in GIT (why?), we can covert .ttf to hex via bin2res :) But I think that would be worse than the problem...
Are we tied to sfd files in any way? Is there maybe another ascii based font format for which a small converter to/from ttf exists? Since fontforge can both export and import ttf we could extend the chain with such a tool and solve both problems. -Hans
On Friday 28 April 2006 10:54, Hans Leidekker wrote:
On Friday 28 April 2006 16:22, Dimi Paun wrote:
Please, that's a trivial utility. As I said, it's a balancing act. It was very simple to have the bin2res, it looks a lot more complicated to have sfd2ttf. If all we wanted is to avoid binaries in GIT (why?), we can covert .ttf to hex via bin2res :) But I think that would be worse than the problem...
Are we tied to sfd files in any way? Is there maybe another ascii based font format for which a small converter to/from ttf exists?
uudecode? Me ducks and runs. Kuba
On Saturday 29 April 2006 00:54, Hans Leidekker wrote:
Are we tied to sfd files in any way? Is there maybe another ascii based font format for which a small converter to/from ttf exists?
Better perhaps would be something that represents in a human-readable text format the contents of the final TTF file, with a Wine internal tool written to compile that to TTF and another to convert the original TTF to that format. -- Troy Rollo - wine(a)troy.rollo.name
On 4/28/06, Dimi Paun <dimi(a)lattica.com> wrote:
As I said, virtually any Java project in existance checks in .jar files, and none of them suffer from any negative ill effect.
jar == zip, not such a big deal -- Travis Watkins http://www.realistanew.com
On Friday, April 28, 2006 18:31, Travis Watkins wrote:
On 4/28/06, Dimi Paun <dimi(a)lattica.com> wrote:
As I said, virtually any Java project in existance checks in .jar files, and none of them suffer from any negative ill effect.
jar == zip, not such a big deal
-- Travis Watkins http://www.realistanew.com
A zip of class (binary) files. - Neil
On 4/28/06, Markus Amsler <markus.amsler(a)oribi.org> wrote:
Hi,
Here's a first version of an sfd2ttf tool based on fontforge-20051205. You can dwonload it from [1]. It consists of 5 files (with Makefile) and has a size of 500K. There's still some dead code lying around, I think I can bring it down to 300K-400K. Is this acceptable?
Just out of interest I ran it through gcov: File 'sfd2ttf.c' Lines executed:23.50% of 2643 File 'sfd.c' Lines executed:30.49% of 2089 File 'tottf.c' Lines executed:51.85% of 2353 And out of 324 functions, 194 aren't being used.
SFD reading was quite easy, the code was well seperated. TTF generation was a bit harder. I decided to output TrueType, with bitmap tables from OpenType. The others ttf variations (full OpenType or even aat (Apple Advanced Typography)) are not supported, as it would make the tool a lot bigger (factor 2-5 or so) and i believe it's not needed (right?).
The fonts aren't generated properly for me unfortunately. I am opening them in gnome-font-viewer; there is a screenshot attached. n0dalus.
Currently we have the following options: - depend on fontforge - add the ttf files - sfd2ttf - use some other font format, with converters (hans's idea). - ?? I personally would also just add the generated ttf files (has someone sent a patch, perhaps it would slip in :-) ). But I think this will not happen, as he could have done it long ago. Even if there is another font format, ttf generation is no trivial task (hardly under 100K). So if AJ refuses to add the ttf files, we have 2 realistic options: stay the way it is or sfd2ttf. Looks like 2 weeks of leaderless flameware. Dimi Paun wrote:
As I said, virtually any Java project in existance checks in .jar files, and none of them suffer from any negative ill effect.
gnuradio on the other side, has a dependency on a verilog compiler for the fpga-firmware (not available for free). You have to download the firmware from another site. They also don't include the configure script. Compared to gnuradio, wine looks developer friendly and pragmatic.
It's insanely big. And it's not a one time thing, we'll have to maintain that.
Maintanance would be minimal. We use only basic ttf features, which are stable. The same with sfd. There are no or minimal dependency on the wine side. Perhaps some gcc warnings and some bugs. n0dalus wrote:
Just out of interest I ran it through gcov: File 'sfd2ttf.c' Lines executed:23.50% of 2643
File 'sfd.c' Lines executed:30.49% of 2089
File 'tottf.c' Lines executed:51.85% of 2353
And out of 324 functions, 194 aren't being used.
Nice to here it built on a different machine. I will have a look at gcov. Half or more of the unused functions are probably due to unused sfd features. With marlett.sfd there are perhaps much less unused functions.
The fonts aren't generated properly for me unfortunately. I am opening them in gnome-font-viewer; there is a screenshot attached.
n0dalus.
Courier.sfd is a bitmap font, perhaps that's the problem. Try marlett.sfd, it's an outline font. Markus
On 4/29/06, Markus Amsler <markus.amsler(a)oribi.org> wrote:
Nice to here it built on a different machine. I will have a look at gcov. Half or more of the unused functions are probably due to unused sfd features. With marlett.sfd there are perhaps much less unused functions.
With marlett.sfd it uses 190 functions out of 324. File 'sfd2ttf.c' Lines executed:19.26% of 2643 File 'sfd.c' Lines executed:29.63% of 2089 File 'tottf.c' Lines executed:54.02% of 2353 So, the distribution is similar but slightly different.
The fonts aren't generated properly for me unfortunately. I am opening them in gnome-font-viewer; there is a screenshot attached.
Courier.sfd is a bitmap font, perhaps that's the problem. Try marlett.sfd, it's an outline font.
Ok, that generated a font. I assume it's supposed to be full of strange symbols (arrows, boxes, etc)? n0dalus.
On Fri, Apr 28, 2006 at 06:34:21PM +0200, Markus Amsler wrote:
Currently we have the following options: - depend on fontforge - add the ttf files - sfd2ttf - use some other font format, with converters (hans's idea). - ??
Btw. if we include other fonts in the future, as example the MS Tahoma replacement "Greenville" we need to include the ttf anyway as there is no source or perhaps only one usable with a nonfree as in money tool. Another possibility would be to split the fonts off of wine. So we have separate source and "binary" packages. Jan
Jan Z. wrote:
Btw. if we include other fonts in the future, as example the MS Tahoma replacement "Greenville" we need to include the ttf anyway as there is no source or perhaps only one usable with a nonfree as in money tool.
Fontforge can convert ttf files to sfd.
Another possibility would be to split the fonts off of wine. So we have separate source and "binary" packages.
We could also add font download/install functionality to winecfg and install the MS core fonts. Markus
participants (11)
-
Dimi Paun -
Dmitry Timoshkov -
Hans Leidekker -
Jan Z. -
Kuba Ober -
Markus Amsler -
Mike McCormack -
n0dalus -
Neil Skrypuch -
Travis Watkins -
Troy Rollo