Werner LEMBERG w...@gnu.org writes:
I'm not too happy that distributions like Debian publish all of the
FreeType demo programs (for example, `ftgamma' has essentially no real
use); maybe this can be improved somehow.
Why? As a Debian user, I'm often glad that the FT demo progs are
there,
:
AC_INIT([t1], [0.0], [Miles Bader mi...@gnu.org])
AC_CONFIG_HEADERS([config.h])
AC_PROG_CC
PKG_PROG_PKG_CONFIG
have_libpng=no
PKG_CHECK_MODULES([libpng], [libpng], [have_libpng=yes], [:])
if test $have_libpng = yes; then
AC_DEFINE([HAVE_LIBPNG], [1], [Define
Werner LEMBERG w...@gnu.org writes:
Does it make sense to completely switch to pkg-config? All of the
above libraries provide .pc files. However, I wonder whether there
are situations where there usage of pkg-config is problematic.
A certain burden is that pkg-config itself must be
Werner LEMBERG w...@gnu.org writes:
After a bit more consideration I suspect it's simply the '0' in
while (0) that's causing all the warnings.
Is this really true? Can you check that explicitly? The `do{...}
while(0)' construction is extremely useful and so common that it
would make the
Werner LEMBERG w...@gnu.org writes:
Behdad Esfahbod (on behalf of Google) contributed support for color
embedded bitmaps (eg. color emoji).
https://color-emoji.googlecode.com/git/specification/v1.html
Only bitmaps? The blog entry doesn't mention any limitation to embedded
bitmaps, and I
Werner LEMBERG w...@gnu.org writes:
What are the void* pointers typically expected to point to...?
Property data structures.
As I suppose these void* values are often pointers to some malloced
memory in many cases, how is it expected that resource management of
that memory is done...?
2012/8/22 Werner LEMBERG w...@gnu.org:
But since (AFAICT) the property mechanism is generic, the type of
the data structure wouldn't be known except to the eventual caller
of FT_Property_Get. Given this, how can FT_Property_Set know the
size of the data structure passed in, to malloc/copy it?
What are the void* pointers typically expected to point to...?
As I suppose these void* values are often pointers to some malloced
memory in many cases, how is it expected that resource management of
that memory is done...? I.e., when the a list gets destroyed because
a FT library is destroyed,
Francesco Abbate francesco@gmail.com writes:
So the problem is still standing about why fonts looks washed with
gamma correction. More important too, what is the better method to
render fonts ? Disable gamma corrections ?
What do you mean by washed out? _What's_ washed out? Regardless
of
I wrote earlier:
[I guess you want to do any blending in a linear space
^ and interpolation too, of course!
(non-gamma-corrected), but obviously whatever you hand off to the
display system should be in whatever space the display system
expects...]
--
Alexei Podtelezhnikov apodt...@gmail.com writes:
Well, I've read that that Apple is going to sell iBooks with
`retina displays' soon, with really impressive DPI values, and I
suspect that other companies will provide similar things, which is
good!
Let me steer this discussion away from
suzuki toshiya mpsuz...@hiroshima-u.ac.jp writes:
Anyway, such discussion is out of the scope of the people saying
i don't get why I feel as some people asking for a bread
(or fermented paste) in the miller's market.
Anyway, I'm sure all the relevant arguments were well-covered in the
Werner LEMBERG w...@gnu.org writes:
/bin/sh: ./configure: Permission denied
Looks like incorrect file permissions. The file
`builds/unix/configure' must be executable.
Try
chmod 755 builds/unix/configure
Another way is to just invoke the configure file as a shell script, e.g.:
sh
Werner LEMBERG w...@gnu.org writes:
I strongly dislike that. I don't consider a font which has been
processed with FreeType (or ttfautohint) a `redistribution in binary
form'. The FTL has never been meant to apply on such cases.
Additionally, I want to make the bytecode created by
hmm
http://www.gnu.org/licenses/gcc-exception-faq.html
--
Quack, n. A murderer without a license.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Werner LEMBERG w...@gnu.org writes:
Today in the morning, while still dozing, I had a great idea how to
largely simplify hinting of composite glyphs, and which solves the
Roboto issue at the same time.
Heh, you have your best coding ideas while half-asleep too eh...?
:}
-miles
--
Monday,
Marek Kasik mka...@redhat.com writes:
our building system warned me that there are .gitignore files
distributed in release tarballs of freetype.
Could you remove them in upcoming releases?
Why should .gitignore files be removed from release tarballs?
They're part of the source code.
A build
suzuki toshiya mpsuz...@hiroshima-u.ac.jp writes:
BTW, during the production of sample PDF, I found that
OpenOffice.org generates wrong checksum for embedded TTF,
so the tricky font detection by the checksum cannot solve
the problem :-(
Could you compare against _both_ the real checksum and
Werner LEMBERG w...@gnu.org writes:
What is improvable, however, is
the algorithm to decide which stems are `main features', and which
features (e.g. serifs) must be handled specially. In particular,
handling of diagonal stems might be improved.
BTW, that's what sort of worried me about the
Werner LEMBERG w...@gnu.org writes:
Below you can find two links to images (from David Turner, who is
testing and evaluating the warping stuff again). Please compare.
http://img848.imageshack.us/img848/9311/wikigitwarpoff.png
http://img852.imageshack.us/img852/3342/wikigitwarpon.png
The developer page on the freetype website says this:
If you are behind a Firewall which disables port 9418, you might try the
slower HTTP protocol:
git clone http://git.sv.nongnu.org/r/freetype/freetype2.git
git clone http://git.sv.nongnu.org/r/freetype/freetype2-demos.git;
[
JustFillBug mozbug...@yahoo.com.au writes:
At 11pt, the bottom of the last few chars will clearly show the
effect. I attached an pic with anti-alias off. anti-aliased version
also shows the effect.
The with blue and no blue renderings are surely different, in terms
of vertical alignment
Behdad Esfahbod beh...@behdad.org writes:
Interesting. I had totally forgotten about libotf. I hope now that new
harfbuzz is in a usable state Kenichi abandons the libotf and helps
with harfbuzz.
Do they do the same thing? From the description it sounds like libotf
is much smaller and more
James Cloos cl...@jhcloos.com writes:
The C version does away-from-zero rounding.
MB Do you have test cases that show this? I tried using random inputs,
MB but even up to billions of iterations, I can't seem to find a set of
MB inputs where my function yields different results from yours.
James Cloos cl...@jhcloos.com writes:
Since FT's C version uses longs, though, this:
int another (long a, long b) {
long r = (long)a * (long)b;
long s = r 31;
return (r + s + 0x8000) 16;
}
That's not correct though, is it? The variable s should be the all
sign portion of the
phil song phils...@techtrex.com writes:
Excuse me ,I don't understand why we need tell the slashdot.org people?
It's just a quick way to generate a lot of publicity about monotype's
dirty tricks...
-Miles
--
We are all lying in the gutter, but some of us are looking at the stars.
James Cloos cl...@jhcloos.com writes:
__asm__ __volatile__ (
movq %1, %%rax\n
imul %2\n
addq %%rdx, %%rax\n
addq $0x8000, %%rax\n
sarq $16, %%rax\n
: =a(result)
: g(a), g(b)
: rdx );
The above code has a latency of 1+5+1+1+1 = 10
Incidentally, you wrote:
The assembly generated by the C code is 45 lines and 158 octets long,
contains six conditional jumps, three each of explicit compares and
tests, and still benchmarks are just as fast. Out-of-order processing
wins out over hand-coded asm. :-/
... but when I follow
Miles Bader mi...@gnu.org writes:
The compiler generates the following assembly:
mov %esi, %eax
mov %edi, %edi
imulq %rdi, %rax
addq$32768, %rax
shrq$16, %rax
The movs there are obviously a bit silly (compiler bug?), but that
output seems
On Tue, Sep 7, 2010 at 4:28 AM, James Cloos cl...@jhcloos.com wrote:
MB == Miles Bader mi...@gnu.org writes:
MB The compiler generates the following assembly:
MB mov %esi, %eax
MB mov %edi, %edi
MB imulq %rdi, %rax
MB addq $32768, %rax
MB shrq $16, %rax
David Turner [EMAIL PROTECTED] writes:
I had correct compilation, without warnings with all the following compilers
though:
MingW (GCC)
Visual C++ 6
Visual C++ 7
Borland C++ 5.5
OpenWatcom C++ (don't remember version)
Win32-LCC (don't remember version)
I also tried several
David Turner [EMAIL PROTECTED] writes:
this will generate an error with certain compilers/pre-processors if
__LP64__ is not defined. generally speaking #if X is not a
portable statement, except if you ensure that the macro is always
defined beforehand.
Is this true according to the C
Sean McBride [EMAIL PROTECTED] writes:
Neither are currently included in glibc (and some effort with google
seems to indicate this is likely to stay this way for the foreseeable
future)
Really? Oh well, that sucks. :)
If you're interested in this sort of thing, it's probably a good idea to
33 matches
Mail list logo
