Werner LEMBERG writes:
>>> BTW, how well does meson support cross compilation?
>>
>> it does support cross-compilation a lot better than cmake
>> on Windows (though compilation fails because of mmap) :
>
> Thanks for checking.
I've done some experimentation with 'picolibc', which uses meson
Werner LEMBERG writes:
> and I couldn't find a commercial feature that would be necessary for
> us. Am I missing something?
People at the Gnome foundation worked with gitlab to add enough features
to the free version to make Gnome developers happy. Seems to be working
fine for freedesktop
Werner LEMBERG writes:
>> It is not about UI but about community. To me,
>> https://gitlab.freedesktop.org feels like the right community to
>> move in. Thanks to Alan for the invitation. The other two
>> communities are too crowded and too commercial.
>
> Mhmm, I think gitlab is a good
David Turner writes:
> for ten different Unix-like system is a portability nightmare.
> On the other hand, building them for a standard Linux distribution, or OS
> X, is a well known problem, so we may consider keeping autotools/libtool as
> an escape hatch for esoteric systems that still exist,
suzuki toshiya writes:
> Is there any recommended alternative? Or, should we accept
> the "modern" situation where we have to execute twice to build
> shared and static libraries?
X and Mesa have switched to Meson, and I've used it in a couple of other
projects (including picolibc). On POSIX
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.
I'd like to be able to know when Freetype will use a strike size for an
FT_Face after the size has been specified. This will let me select
monochrome rendering for any glyphs which don't happen to have bitmaps
in the strike.
Right now, I've coded up a fairly ugly hack which attempts to guess when
a different
route ?
I'm not sure. If I remember correctly, Keith Packard explicitly decided
that he didn't want the filtering to cross pixel borders because that
might possibly confuse xterm and other character cell based software.
Stupid reason, if you ask me.
Lame, perhaps, but still
On Sun, 2006-08-27 at 23:57 +0200, Tor Andersson wrote:
I'm not sure I understand this. What's your definition of character metrics
here? I'm grounded in the postscript world where the only metrics that
matter are the origin and advance width.
For many applications, the extent of the rendered
On Fri, 2006-07-14 at 09:58 +0900, [EMAIL PROTECTED] wrote:
Hi
On Thu, 13 Jul 2006 15:52:23 -0700
Tom Fukushima [EMAIL PROTECTED] wrote:
What does the last sentence mean?
Since FreeType2 provides unified API for various font formats,
the fundamental API is designed for ASCII font name:
On Tue, 2006-01-17 at 15:12 -0800, George Williams wrote:
I was told so when I implemented them in fontforge. But I wasn't in the
initial discussions so I'm not the best source.
I also recall discussions which discovered that the .otb extension was
otherwise unused in most of the world. It
On Mon, 2005-12-12 at 20:12 +0100, Juliusz Chroboczek wrote:
Keith,
I'm not quite sure what you mean by ``round-trip'', but that might be
more difficult than you think: as you've surely noticed, fonttosfnt
crops glyphs by default, as there's no reason to propagate X's ``-c-''
fonts into
On Fri, 2005-12-09 at 01:07 +0100, Werner LEMBERG wrote:
Hmm, why not simply adding a special `BDF ' table which holds all
properties? This should be straightforward, and you get lossless
conversion.
Yes, this was my plan. I got side-tracked before I managed to implement
it though.
I need
On Sat, 2005-07-16 at 17:33 -0400, Jeremiah Coyle wrote:
Hello,
Wondering if FreeType supports any font format which supports 32bit
color depth and transparency.
SVG seems like a better plan to me. Glyph-based tools all assume that
glyphs are purely shape information and have no intrinsic
14 matches
Mail list logo