Free version gargoyle?

[Akien]

Hi,

I was wondering if a totally free (in terms of license) version of
gargoyle could be realized, so that gargoyle can be broadcast on
official repositories.
For instance, Mandriva 2009.1 is currently in RC2, and it is still
possible to submit some free software to its repositories. I would be
glad to see a gargoyle RPM that can be easily downloaded and
installed.

A free version of gargoyle would mean a version without the
copyrighted interpreters I think. I don't know if it is possible,
meaningful or even desirable ;)

Regards,
Rémi Verschelde.

[farvardin]

As someone suggested on our IF forum, a compilation flag could be
enough to allow the various distributions to easily strip-out the
interpreters they don't think is "free enough"

I think those terps don't have any problem with linux distributions:
AGiliTy Frotz Geas Git Glulxe JACL Level9 JACL Magnetic Scare so they
should be included without problem.

TADS is certainly not Free enough, but it may be possible to ask the
author if he wishes to change the license.

I don't know about Alan and Hugo, but it may worth asking the author
if they wish to release them under a license compatible with the linux
distribution if it's not already the case.

I don't know about the legal case of the fonts, it's probably
important to be sure about their status.

[Stuart Allen]

I think a completely free version of Gargoyle is very desirable. It
would be great to have a packaged version available in popular
distributions so that we could distribute games as easily installable
packages that depend on it.

Removing non-free interpreters obviously isn't hard, but I think there
would be a good chance that authors would change to a less restrictive
licence if it meant being included. If that didn't happen it would be a
shame not to have them some interpreters included, it is better than not
having any interpreters at all. Issues like fonts are obviously a lot
trickier to investigate and resolve, but not insurmountable. I'll
starting looking to see what I can find out about the ones that are
currently included.

Stuart

[Ben Cressey]

TADS is certainly not Free enough, but it may be possible to ask the
author if he wishes to change the license.

There was a thread on raif a while back where someone mentioned Mike Roberts had granted permission to release a TADS implementation under the GPL.  See:
http://groups.google.com/group/rec.arts.int-fiction/msg/f6babebe39bd8724?hl=en

Not sure he would be willing to do the same for Gargoyle but it seems possible.

I don't know about Alan and Hugo, but it may worth asking the author
if they wish to release them under a license compatible with the linux
distribution if it's not already the case.

If someone wants to take the lead on this, that would be great.  I don't feel great about asking software authors to change licenses.  I figure there's enough information online about the pros / cons of all the options that they likely made the choice they did for a reason, and I don't have the requisite zeal to push convincingly for a change.
 

I don't know about the legal case of the fonts, it's probably
important to be sure about their status.

Ubuntu and presumably Debian ship with Charter Bitstream and Luxi Mono installed.  I assume that means they're free enough for just about any distro, so fonts are likely a non-issue unless we add new ones, e.g. Junicode.

[stormi]

Indeed, Mike Roberts released TADS under GPL specifically to allow
distribution of QTADS, because of QT3's license. According to me, we
could practically take the TADS source code from the QTADS package and
ship it with Gargoyle. It would be legal, but I doubt that Mike
Roberts would appreciate, that's why it's better to ask him directly.
I already asked him some months ago and he said he was considering
taking a "free" license, but he couldn't say when he will, if he does.

However, what about a light version of gargoyle without the non free
interpreters ? As a packager for Mandriva Linux I'm ready to submit
such a version to the repositories as soon as it is available.

[farvardin]

I can try to contact those authors, and I'll send them an email this
evening.

[farvardin]

In the case the Alan author agrees to license his terp under a gpl or
bsd license, wouldn't the spa.h and spa.c source interfer with the
inclusion of the terp into some linux distributions:

http://code.google.com/p/garglk/source/browse/trunk/terps/alan3/spa.h

"Users may copy or modify
this file without charge, but are not authorized to license or
distribute it to anyone else except as part of a product or program
developed by the user."

[stormi]

Mike Roberts has agreed to licence the TADS interpreter under GPL for
gargoyle too.

With free interpreters for Z-CODE, glulxe and TADS, a free light
version of gargoyle is becoming more and more interesting.

farvardin, did you get any answer from the other authors ?

Ben, what about a parallel free version of gargoyle without the non-
free interpretors (until they become free themselves, if it happens
one day) ?

[Ben Cressey]

With the TADS change, the interpreters for the most popular / current formats are covered by free licenses.

- TADS 2/3 and Frotz are GPL.
- Git is MIT (changed in 1.2.3).
- Glulxe is (or is intended to be) BSD-style.
- Agility, Geas, Jacl, Level 9, Magnetic Scrolls, Nitfol and Scare are GPL.

That leaves AdvSys, Alan, and Hugo.  It sounds as if Thomas Nilsson is considering a license change.  Perhaps David Michael Betz (AdvSys) and Kent Tessman (Hugo) would do so as well?

I can add a "non free" compile option for Jam to avoid building the non-free interpreters, but if we can keep everything together and under compatible licenses, that would be great.

[Kritsada Piriyakitpaiboon]

All these developments for garglk into the free software direction
really excite me. Please do make an announcement when garglk appears
in the ubuntu repository. Finally, an one-stop standard-defining
interpreter for the linux mainstream is becoming a reality.

[stormi]

Any news from AdvSys, Alan, and Hugo ?

[Ben Cressey]

Any news from AdvSys, Alan, and Hugo ?

Current status as far as I know:

- Thomas Nilsson is considering the BSD/GPL proposal that Eric sent him.  I'll follow up in a few weeks to see if he's made a choice.  He seems receptive to the idea, and this project has done a fair amount of work on the Alan interpreter (adding 64-bit support), so I'm optimistic that he will see the value.

- Kent Tessman indicates that it's a possibility and the ball is in his court to reply.

- No word about AdvSys.  I'm not sure if we've made contact.  I'll send an email to David Betz if I can find a working address.

[Ben Cressey]

- No word about AdvSys.  I'm not sure if we've made contact.  I'll send an email to David Betz if I can find a working address.

I contacted David Betz this morning and he graciously granted permission to distribute AdvSys under the terms of the BSD license.

[stormi]

Hi,

Are there any news from Thomas Nilsson and Kent Tessman ? I'm ready to
package gargoyle for Mandriva and include it in the official
repositories, but the licences of Alan and Hugo still prevent me from
doing it.

If they didn't decide yet, or decided to refuse, is it possible to
distribute an archive without those 2 interpreters, which could be
used by the main linux distributions for inclusion in their
repositories ? Thus there would be the complete gargoyle including
Alan and Hugo, and a light version without them.

[Ben Cressey]

Are there any news from Thomas Nilsson and Kent Tessman ? I'm ready to
package gargoyle for Mandriva and include it in the official
repositories, but the licences of Alan and Hugo still prevent me from
doing it.

No word yet.  I'm optimistic but ultimately it's their decision to make (or not.)
 

If they didn't decide yet, or decided to refuse, is it possible to
distribute an archive without those 2 interpreters, which could be
used by the main linux distributions for inclusion in their
repositories ? Thus there would be the complete gargoyle including
Alan and Hugo, and a light version without them.

I don't have a problem with a "Gargoyle light" that leaves out Alan and Hugo.  It's disappointing but realistically most newer games will not use either system.  Players sophisticated enough to find and download older games will hopefully be in a better position to find options for Alan and Hugo terps.

I don't intend to change the strategy for the project's packages, but it's trivial to compile Gargoyle without any given interpreter.  Just edit terps/Jamfile and change the MAKE_TERP value in question to NO.

[Christopher Armstrong]

Well, since Debian (and other distros) also host the source packages
in their repositories (and require those source packages to be free
software), a source package will need to be prepared that doesn't
include the Alan and Hugo interpreters, whether it's made by upstream
Garglk or the packagers.

--
Christopher Armstrong
http://radix.twistedmatrix.com/
http://planet-if.com/

[stormi]

Yes, I was going to say something like that. We try as much as
possible to include unmodified upstream tarballs in the source
packages, to ease package maintenance. Tarballs that mix free and non
free software force us to modify the original tarball at each new
release, that's why a totally free tarball at the project level would
ease packager's work :)

[Sylvain Beucler]

Hi,

I'm part of the Debian/Ubuntu Game Team and I was working on a
'gargoyle-free' package when I saw this thread :)

I'm currently testing it with disabling the Alan, TADS and Hugo
interpreters, and disabling Luxi fonts support (which, as far as I can
see, isn't free nor included in Debian as mentioned in the thread).

Aside from that I'm looking for help with 2 technical matters:

- How can I dynamically compile against libsdl, libfreetype, etc.,
from the system, instead of bundling the versions in support/ ?
I don't have much experience with Jam.

- Optionaly: is there a way to use Bitstream from the system
(e.g. through fontconfig) rather than the bundled version? Though as
the bundled version is specifically modified this may not be a good
idea?

Thanks!

--
Sylvain
PS: http://groups.google.com/group/garglk-dev has a mistake, you need
to subcribe with garglk-dev...@googlegroups.com (note the '+')

[Eric Forgeot]

I'm afraid I can't answer you Sylvain, as far as I know, when running jam inside the garglk folder, it doesn't bundle anything in support, this folder, if I understand well, is only for the devel lib to help compiling the package. After the compilation, the binaries are dynamically linked into the one from the system (try with ldd). But maybe I'm wrong and I didn't understand how it works.

About the licencing issue, Thomas the developer of Alan answered me while he wanted to keep some control on how Alan is evolving, he hadn't anything against opensourcing the interpreter, but I didn't get any news about this recently.

[Sylvain Beucler]

> when running jam inside the garglk folder, it doesn't bundle
> anything in support, this folder, if I understand well, is only for
> the devel lib to help compiling the package. After the compilation,
> the binaries are dynamically linked into the one from the system
> (try with ldd).

Silly me, I tried 'ldd' on an interpreter instead of on 'libgarglk.so'
:)

SDL_sound is built statically though, I'll have a closer look.

> About the licencing issue, Thomas the developer of Alan answered me while he
> wanted to keep some control on how Alan is evolving, he hadn't anything
> against opensourcing the interpreter, but I didn't get any news about this
> recently.

Great!

--
Sylvain

[Ben Cressey]

I'm currently testing it with disabling the Alan, TADS and Hugo
interpreters, and disabling Luxi fonts support (which, as far as I can
see, isn't free nor included in Debian as mentioned in the thread).

There should be no reason to disable TADS.  Mike Roberts has dual-licensed the interpreters and allowed them to be distributed under the GPL.

Not sure what to do about Luxi.  Do you have a different monospaced font that you are replacing it with?  Seems like it's potentially a concern for this project as well.

The fonts are also included in the source tree as the .hex files under garglk/.  These are imported into fontdata.c, and loaded into memory at runtime.  I believe you could replace the .hex files with zero byte equivalents, provided that you override the default fonts in garglk.ini for the ones you replace.

You could also generate hex dumps of the relevant font files and include those in fontdata.c instead.  This is a little less brittle from the library's perspective, as it always expects to be able to supply default fonts, even in the absence of a suitable garglk.ini.

I can help with that part if you point me toward the fonts you're contemplating.

 

- How can I dynamically compile against libsdl, libfreetype, etc.,
 from the system, instead of bundling the versions in support/ ?
 I don't have much experience with Jam.

As Eric mentioned and you've already discovered, SDL_sound is the only statically built library.  This was done to get around a clash between SDL_mixer and SDL_sound, when the latter was built with MOD support.  I believe this is resolved in SDL_sound version 1.0.3 and greater, so it should not be an issue moving forward.

I've attached a small patch that should re-enable dynamic linking to SDL_sound.
 

- Optionaly: is there a way to use Bitstream from the system
 (e.g. through fontconfig) rather than the bundled version? Though as
 the bundled version is specifically modified this may not be a good
 idea?

I wouldn't really recommend this, but the current way to use different fonts is to modify garglk.ini with the full path to the desired font file.  You'll miss out on the kerning changes that Tor made to the Bitstream fonts, however.

Regards,
Ben

[Tor Andersson]

> I wouldn't really recommend this, but the current way to use different fonts
> is to modify garglk.ini with the full path to the desired font file.  You'll
> miss out on the kerning changes that Tor made to the Bitstream fonts,
> however.

For whatever it's worth I think you should just include Charis SIL instead of
the Bitstream Charter fonts that I modified. It's a font based on the
same design,
but is more complete and uses the open font license.

http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=CharisSILFont

[Ben Cressey]

For whatever it's worth I think you should just include Charis SIL instead of
the Bitstream Charter fonts that I modified. It's a font based on the
same design,
but is more complete and uses the open font license.

Well, that's good enough for me.  It looks like they've even released an updated version of Charis SIL since the last time we discussed it.

[Sylvain Beucler]

Hi,

On Fri, Sep 11, 2009 at 09:49:55AM -0700, Ben Cressey wrote:
> There should be no reason to disable TADS. Mike Roberts has dual-licensed
> the interpreters and allowed them to be distributed under the GPL.

Great!

> Not sure what to do about Luxi. Do you have a different monospaced font
> that you are replacing it with? Seems like it's potentially a concern for
> this project as well.

Embarrassingly I just tested with using Charter instead.

A quick 'fc-list :spacing=mono' shows the following potential alternatives:
Bitstream Vera Sans Mono
Courier 10 Pitch
DejaVu Sans Mono
FreeMono
Liberation Mono
Nimbus Mono L

Any preference? :)
I'll make some tests.

> The fonts are also included in the source tree as the .hex files under
> garglk/. These are imported into fontdata.c, and loaded into memory at
> runtime. I believe you could replace the .hex files with zero byte
> equivalents, provided that you override the default fonts in garglk.ini for
> the ones you replace.

This makes me wonder: garglk.ini is not installed anywhere by default.
Would it make sense to create a site-wide /etc/garglk.ini? Running
without garglk.ini seemed to run fine to me though.

> > - How can I dynamically compile against libsdl, libfreetype, etc.,
> > from the system, instead of bundling the versions in support/ ?
> > I don't have much experience with Jam.
> >
>
> As Eric mentioned and you've already discovered, SDL_sound is the only
> statically built library. This was done to get around a clash between
> SDL_mixer and SDL_sound, when the latter was built with MOD support. I
> believe this is resolved in SDL_sound version 1.0.3 and greater, so it
> should not be an issue moving forward.
>
> I've attached a small patch that should re-enable dynamic linking to
> SDL_sound.

Thanks. I modified it to also edit garglk/Jamfile, and remove -lvorbis
and -lsmpeg which are not directly used anymore:
http://git.debian.org/?p=pkg-games/gargoyle-free.git;a=blob;f=debian/patches/sdl_sound_debian.patch;hb=HEAD

> > - Optionaly: is there a way to use Bitstream from the system
> > (e.g. through fontconfig) rather than the bundled version? Though as
> > the bundled version is specifically modified this may not be a good
> > idea?
>
> I wouldn't really recommend this, but the current way to use different fonts
> is to modify garglk.ini with the full path to the desired font file. You'll
> miss out on the kerning changes that Tor made to the Bitstream fonts,
> however.

If Gargoyle switches to SIL fonts, I'll probably contribute a patch to
fallback to fontconfig, for the following reasons:

- I know that Debian and Fedora have policies against bundling fonts
in packages when they are already available, and they feel strongly
about it ;)

- Bundling fonts that are not compatible with the GPL in a GPL program
causes legal issues. In FreeDink (an adventure/rpg game and engine),
I'm using a similar technique, where a default GPL-compatible font
is bundled in the program so the engine can always display error
messages, but it looks for other fonts through fontconfig:
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/gfx_fonts.c

Also, at:
http://git.debian.org/?p=pkg-games/gargoyle-free.git;a=tree
you'll find the current packaging. Right now, it installs everything
but the wrapper in /usr/lib/gargoyle, and modifies to wrapper to look
there (instead of in the current directory). The wrapper itself is
installed in /usr/games/, which is the FHS location for games
binaries. (It's called 'gargoyle-free' so that people understand why
it doesn't support Alan and Hugo.)

However this means users cannot (e.g.) type 'glulxe' directly to run
a garglk-enabled glulxe, so I'm wondering about installing them all in
/usr/games, and compile the interpreters so they look for garglk.so in
/usr/lib/gargoyle/. Or maybe garglk.so should get a proper soname and
version, and be installed in /usr/lib? What do you think?

--
Sylvain

[Sylvain Beucler]

> A quick 'fc-list :spacing=mono' shows the following potential alternatives:
> Bitstream Vera Sans Mono
> Courier 10 Pitch
> DejaVu Sans Mono
> FreeMono
> Liberation Mono
> Nimbus Mono L
>
> Any preference? :)
> I'll make some tests.

Here are my remarks under the form of copy/paste-able garglk.ini
config bits :)

Courier (Serif) and Bitstream Vera Sans Mono / DevuVu Sans Mono are
nice enough.

Do you know about good free Mono Serif fonts to try?

# FreeFont Mono - Too small, a bit hard to read
#monor /usr/share/fonts/truetype/freefont/FreeMono.ttf
#monob /usr/share/fonts/truetype/freefont/FreeMonoBold.ttf
#monoi /usr/share/fonts/truetype/freefont/FreeSansOblique.ttf
#monoz /usr/share/fonts/truetype/freefont/FreeMonoBoldOblique.ttf

# Nimbus Mono L - No BoldOblique, very similar to FreeFont mono
#monor /usr/share/fonts/type1/gsfonts/n022003l.pfb
#monob /usr/share/fonts/type1/gsfonts/n022004l.pfb
#monoi /usr/share/fonts/type1/gsfonts/n022023l.pfb
#monoz /usr/share/fonts/type1/gsfonts/n022023l.pfb

# Liberation Mono - Readable but Sans (not Serif) and a bit blurry
#monor /usr/share/fonts/truetype/ttf-liberation/LiberationMono-Regular.ttf
#monob /usr/share/fonts/truetype/ttf-liberation/LiberationMono-Bold.ttf
#monoi /usr/share/fonts/truetype/ttf-liberation/LiberationMono-Italic.ttf
#monoz /usr/share/fonts/truetype/ttf-liberation/LiberationMono-BoldItalic.ttf

# Courier - Serif but smaller than Luxi (bigger and bolder than FreeFont Mono though)
#monor /usr/share/fonts/X11/Type1/c0419bt_.pfb
#monob /usr/share/fonts/X11/Type1/c0583bt_.pfb
#monoi /usr/share/fonts/X11/Type1/c0582bt_.pfb
#monoz /usr/share/fonts/X11/Type1/c0611bt_.pfb

# Bitstream Vera Sans Mono - Readable but Sans (not Serif)
#monor /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf
#monob /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBd.ttf
#monoi /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoIt.ttf
#monoz /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBI.ttf

# DejaVu Sans Mono - Derivative of Bitstream so very similar
#monor /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf
#monob /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf
#monoi /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Oblique.ttf
#monoz /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-BoldOblique.ttf

# Luxi - Current one. Serif.
#monor /usr/src/gargoyle-2009-08-25/garglk/fonts/LuxiMonoRegular.pfb
#monob /usr/src/gargoyle-2009-08-25/garglk/fonts/LuxiMonoBold.pfb
#monoi /usr/src/gargoyle-2009-08-25/garglk/fonts/LuxiMonoBoldOblique.pfb
#monoz /usr/src/gargoyle-2009-08-25/garglk/fonts/LuxiMonoOblique.pfb

--
Sylvain

[Sylvain Beucler]

Hi,

Attached is a patch to use a different monospace font.

Currently I'm trying DejaVu Sans Mono, though a Serif font may be more
appropriate. Since DejaVu Sans Mono's license is not compatible with
the GNU GPL, it cannot be bundled in the executable, so the patch
locates and loads it using FontConfig.

Do you think we could include this patch in the next release? We
could do something like: "if luxi is present, use it, else locate and
load dejavu from the system".

By the way, games such as "The Moon Watch" refer to the original
builtin fonts in their .ini configuration: "LuxiMonoRegular",
"LuxiMonoBold", "LuxiMonoOblique", "LuxiMonoBoldOblique". In such
case, we probably should keep the internal font names as-is (not
rename them) and silently remap them. This applies to this
replacement as well as to the Charter->SIL change that was discussed
yesterday.

Also, all the patches the packaging currently needs can be browsed at:
http://git.debian.org/?p=pkg-games/gargoyle-free.git;a=tree;f=debian/patches;hb=HEAD

I wish to keep as few patches as possible here :)

--
Sylvain

[Ben Cressey]

Well, that's good enough for me.  It looks like they've even released an updated version of Charis SIL since the last time we discussed it.

Call me fickle but I'm not as excited about Charis SIL now.  It seems to be quite bloated, and it's a weird sort of bloat: the included glyphs appear to target minority languages rather than offering greater coverage of major Western European scripts.

Also it's somewhat larger and darker on screen, which I don't care for.

I've attached three screenshots:
- One for reference, using Charter as prop and Luxi as mono.
- One with Charis as prop and Vera Sans as mono.
- One with Linux Libertine as prop and Liberation as mono.

Libertine actually looks closer to Charter than Charis does, in many respects.  I don't particularly like the uppercase glyphs, especially the rounded ones like C, G, and O, but on the whole I prefer it to Charis.

Not sure what to say about the monospace fonts.  Sylvain's list of the unencumbered choices appears to be exhaustive.  Liberation Mono might be the best compromise here: it's not serif but it's also not Vera.

[Sylvain Beucler]

On Mon, Sep 14, 2009 at 12:29:12PM -0700, Ben Cressey wrote:
> Not sure what to say about the monospace fonts. Sylvain's list of the
> unencumbered choices appears to be exhaustive. Liberation Mono might be the
> best compromise here: it's not serif but it's also not Vera.

My list was not meant to be exhaustive :) (not sure whether you're
saying that it was, or that you didn't find more alternatives)

I personaly prefer Bitstream Vera Sans Mono / DejaVu Mono rather than
Liberation Mono - is there any problem with Vera?

--
Sylvain

[Sylvain Beucler]

Hmm, with the patch attached :)

The latest version is here:
http://git.debian.org/?p=pkg-games/gargoyle-free.git;a=blob;f=debian/patches/dfsg_replace_luximono_font.patch;hb=HEAD

--
Sylvain

[Ben Cressey]

My list was not meant to be exhaustive :) (not sure whether you're
saying that it was, or that you didn't find more alternatives)

Your list covers all suitable monospace typefaces available under free licenses, at least as far as I can tell after a lot of Google searches.

The only notable omission is Inconsolata, but that's unfinished and not available in all the necessary fonts.  Might be worth keeping an eye on, however.
 

I personaly prefer Bitstream Vera Sans Mono / DejaVu Mono rather than
Liberation Mono - is there any problem with Vera?

Tor dislikes Vera.  Given the origin and mandate of the project, I'm unwilling to patch in a font he considers ugly.  Granted, there aren't many suitable alternatives.  I'd like to find a middle ground so that Debian users don't wind up getting a different mono font from the rest of the community.  But if it's not Liberation Mono then it may not exist yet, which would mean that we stick with Luxi at the upstream level.

[Sylvain Beucler]

For testing, I made a few tests with these fonts, plus a couple other
ones I found.

Results at:
http://www.beuc.net/tmp/gargoyle/moonwatch/

I may do the same with another game.

# FreeFont Mono - Too small, a bit hard to read
#monor /usr/share/fonts/truetype/freefont/FreeMono.ttf
#monob /usr/share/fonts/truetype/freefont/FreeMonoBold.ttf
#monoi /usr/share/fonts/truetype/freefont/FreeSansOblique.ttf
#monoz /usr/share/fonts/truetype/freefont/FreeMonoBoldOblique.ttf

# Nimbus Mono L - No BoldOblique, Serif, very similar to FreeFont mono

#monor /usr/share/fonts/type1/gsfonts/n022003l.pfb
#monob /usr/share/fonts/type1/gsfonts/n022004l.pfb
#monoi /usr/share/fonts/type1/gsfonts/n022023l.pfb
#monoz /usr/share/fonts/type1/gsfonts/n022023l.pfb

# Liberation Mono - Readable but Sans (not Serif) and a bit blurry
#monor /usr/share/fonts/truetype/ttf-liberation/LiberationMono-Regular.ttf
#monob /usr/share/fonts/truetype/ttf-liberation/LiberationMono-Bold.ttf
#monoi /usr/share/fonts/truetype/ttf-liberation/LiberationMono-Italic.ttf
#monoz /usr/share/fonts/truetype/ttf-liberation/LiberationMono-BoldItalic.ttf

# Courier - Serif but smaller than Luxi (bigger and bolder than FreeFont Mono though)
#monor /usr/share/fonts/X11/Type1/c0419bt_.pfb
#monob /usr/share/fonts/X11/Type1/c0583bt_.pfb
#monoi /usr/share/fonts/X11/Type1/c0582bt_.pfb
#monoz /usr/share/fonts/X11/Type1/c0611bt_.pfb

# Bitstream Vera Sans Mono - Readable but Sans (not Serif)
#monor /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf
#monob /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBd.ttf
#monoi /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoIt.ttf
#monoz /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBI.ttf

# DejaVu Sans Mono - Derivative of Bitstream so very similar
#monor /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf
#monob /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf
#monoi /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Oblique.ttf
#monoz /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-BoldOblique.ttf

# OCRA - Quite bold (changes window size)
#monor /usr/share/fonts/truetype/ttf-ocr-a/OCRA.ttf
#monor /usr/share/fonts/truetype/ttf-ocr-a/OCRABold.ttf
#monoi /usr/share/fonts/truetype/ttf-ocr-a/OCRAItalic.ttf
#monoz /usr/share/fonts/truetype/ttf-ocr-a/OCRAItalic.ttf

# Courier BGP - similar to DejaVu Sans Mono
#monor /usr/share/fonts/truetype/ttf-bpg-georgian/BPG_Courier.ttf
#monob /usr/share/fonts/truetype/ttf-bpg-georgian/BPG_Courier_Bold.ttf
#monoi /usr/share/fonts/truetype/ttf-ocr-a/OCRAItalic.ttf
#monoz /usr/share/fonts/truetype/ttf-ocr-a/OCRAItalic.ttf

# Inconsolata - small (changes window size)
#monor /usr/share/fonts/truetype/ttf-inconsolata/Inconsolata.otf
#monob /usr/share/fonts/truetype/ttf-inconsolata/Inconsolata.otf
#monoi /usr/share/fonts/truetype/ttf-inconsolata/Inconsolata.otf
#monoz /usr/share/fonts/truetype/ttf-inconsolata/Inconsolata.otf

# Zelda DX - for fun (changes window size)
#monor /usr/share/fonts/truetype/aenigma/zeldadxt.ttf
#monob /usr/share/fonts/truetype/aenigma/zeldadxt.ttf
#monoi /usr/share/fonts/truetype/aenigma/zeldadxt.ttf
#monoz /usr/share/fonts/truetype/aenigma/zeldadxt.ttf

# Luxi - Current one. Serif.
#monor /usr/src/gargoyle-2009-08-25/garglk/fonts/LuxiMonoRegular.pfb
#monob /usr/src/gargoyle-2009-08-25/garglk/fonts/LuxiMonoBold.pfb
#monoi /usr/src/gargoyle-2009-08-25/garglk/fonts/LuxiMonoBoldOblique.pfb
#monoz /usr/src/gargoyle-2009-08-25/garglk/fonts/LuxiMonoOblique.pfb

monor LuxiMonoRegular
monob LuxiMonoBold
monoi LuxiMonoOblique
monoz LuxiMonoBoldOblique

--
Sylvain

[Ben Cressey]

The latest version is here:
http://git.debian.org/?p=pkg-games/gargoyle-free.git;a=blob;f=debian/patches/dfsg_replace_luximono_font.patch;hb=HEAD

I like the idea of using fontconfig instead of built-in fonts.  It appears to work under Windows as well, so it's quite possible that something like this will become the new way for Gargoyle to handle fonts.  I'll take a pass at it in the next few days.

[Dannii]

Have you considered Libertine?

http://linuxlibertine.sourceforge.net/Libertine-EN.html

[Dannii]

Oh wait, the problem is with mono fonts... Libertine won't help then.

[Ben Cressey]

Oh wait, the problem is with mono fonts... Libertine won't help then.

I read your message and got really excited thinking that Libertine had released a monospaced variant.  That would've been great.  Ah well.

[Ben Cressey]

I like the idea of using fontconfig instead of built-in fonts.  It appears to work under Windows as well, so it's quite possible that something like this will become the new way for Gargoyle to handle fonts.  I'll take a pass at it in the next few days.

I've updated the library to use fontconfig in two different cases:

- When bundled fonts are disabled.  This is a new option in the main project Jamfile.  If bundled fonts are disabled, it requires some special attention from packagers to map the original font names to valid fonts on the platform in question.  (Those fonts should either be available by default or included as a package dependency.)

- When the most relevant garglk.ini specifies a partial font filename, and Freetype fails to load it from the current working directory. The library used to abort with an error but now it checks with fontconfig to see if a system font might have been meant instead.

I'm less excited about fontconfig after having used it.  The developer docs are terrible, and if the partial filename search is a horrible abuse of the fontconfig mechanism, it's because I couldn't hit upon the correct syntax to express the concept in a more organic way.  But it's in and it gets the job done, so it's hard to complain.

Thanks for the initial fontconfig patch, Sylvain.  I think the merged version is essentially compatible, though the font queries in fontdata.c will still need to be updated.

Regards,
Ben

[Sylvain Beucler]

On Fri, Sep 18, 2009 at 02:04:12PM -0700, Ben Cressey wrote:
> > I like the idea of using fontconfig instead of built-in fonts. It appears
> > to work under Windows as well, so it's quite possible that something like
> > this will become the new way for Gargoyle to handle fonts. I'll take a pass
> > at it in the next few days.
> >
>
> I've updated the library to use fontconfig in two different cases:
>
> - When bundled fonts are disabled. This is a new option in the main project
> Jamfile. If bundled fonts are disabled, it requires some special attention
> from packagers to map the original font names to valid fonts on the platform
> in question. (Those fonts should either be available by default or included
> as a package dependency.)
>
> - When the most relevant garglk.ini specifies a partial font filename, and
> Freetype fails to load it from the current working directory. The library
> used to abort with an error but now it checks with fontconfig to see if a
> system font might have been meant instead.
>
> I'm less excited about fontconfig after having used it. The developer docs
> are terrible, and if the partial filename

> search<http://code.google.com/p/garglk/source/browse/trunk/garglk/fontdata.c?spec=svn280&r=280#166>is

> a horrible abuse of the fontconfig mechanism, it's because I couldn't
> hit
> upon the correct syntax to express the concept in a more organic way. But
> it's in and it gets the job done, so it's hard to complain.
>
> Thanks for the initial fontconfig patch, Sylvain. I think the merged
> version is essentially compatible, though the font queries in fontdata.c
> will still need to be updated.

Gargoyle entered Debian "unstable" :)
http://packages.debian.org/sid/gargoyle-free

This means it should be included in the next Debian release.

There are still a few things to fix, for example it's not possible to
call 'glulxe' directly, but it's not critical right now.

By the way, about fontconfig: the example utilities are usually a good
source of "documentation", maybe you'll want to check the 'fc-match'
source code.

--
Sylvain