Werner,
I know I'm fairly opinionated when it comes to library design, but thought
share my thoughts anyway. Personally I think FreeType's public API is largely
over-engineered, and the proposed property service is a big step in that
direction. As a user of the library, I don't care about
On 08/29/2012 09:58 AM, Alexei Podtelezhnikov wrote:
Any plans for Freetype3?
I'm been thinking about that...
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Suzuki-san,
Care to summarize your findings?
Thanks,
behdad
On 09/04/2012 06:11 AM, suzuki toshiya wrote:
Hi,
Just I did a preliminary investigation of FreeType2 API popularity.
What I did was following:
1) Get the catalogs of the binary packages of Linux distributions.
Debian:
Yep. Emscripten is great. Let me also tell you that Emscripten has also been
used to crosscompile both HarfBuzz and GLyphy to JS+WebGL. Interesting times
indeed!
On 12-10-23 12:23 PM, Dave Crossland wrote:
Hi
Wow: http://www.syntensity.com/static/freetype.html
TrueType Fonts in
On 12-10-31 09:25 AM, Nicolas Rougier wrote:
What I had in mind was to generate the distance field on the software side
using exact distances (instead of approximating them from a rasterized glyph)
an to store the results in a texture. I know the result will be not so good
at very high
On 12-10-31 01:16 PM, Alexei Podtelezhnikov wrote:
On Wed, Oct 31, 2012 at 12:03 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 12-10-31 07:25 AM, Alexei Podtelezhnikov wrote:
On Tue, Oct 30, 2012 at 6:56 AM, Nicolas Rougier
nicolas.roug...@inria.fr wrote:
My question relates to a more
[Excuse my cross-lists posting]
A while back I wrote a document about the interactions of high-density
displays and font rendering options. I just went ahead and made it public,
so, enjoy!
http://goo.gl/yf3M7
--
behdad
http://behdad.org/
___
Hi,
I like to make cairo resize bitmap strikes when the requested and returned
size are drastically different. Think about it this way: You request a glyph
at size 80ppem, and FreeType returns an image at 16ppem because that's the
biggest size the font had and the font is not scalable. I like
On 12-12-21 03:29 AM, Werner LEMBERG wrote:
I like to make cairo resize bitmap strikes when the requested and
returned size are drastically different. Think about it this way:
You request a glyph at size 80ppem, and FreeType returns an image at
16ppem because that's the biggest size the
On 12-12-21 04:18 PM, Werner LEMBERG wrote:
FreeType doesn't return a 16ppem glyph image at 80ppem for a bitmap
font; this rather causes an error.
Really? Even with SFNT-based bitmap-only fonts? That's definitely
not what I'm observing.
*Blush* Oh! Sounds like a bug. Please send me
It looks to me that David rewrote ttsbit, the code loading SFNT embedded
bitmaps, to be more memory-optimized, but then had to keep the old code for
when old internals config option is enabled. That means the functionality
is duplicated now, in ttsbit.c and ttsbit0.c. At least by default, old
On 13-01-10 03:03 PM, Alexei Podtelezhnikov wrote:
On Thu, Jan 10, 2013 at 1:38 PM, Behdad Esfahbod beh...@behdad.org wrote:
Hi,
There's a bug against Webkit:
https://bugs.webkit.org/show_bug.cgi?id=102374
that I think points to a problem in FreeType. Simply put: for fonts that
have
On 13-01-10 03:53 PM, David Turner wrote:
It's been a long time, but I think it's really time we completely remove the
old-internals hack and corresponding code. It was only needed transitively and
all client code should have been modified to not require it.
Also, sorry, but the Android
On 13-01-10 04:08 PM, Behdad Esfahbod wrote:
On 13-01-10 03:53 PM, David Turner wrote:
It's been a long time, but I think it's really time we completely remove the
old-internals hack and corresponding code. It was only needed transitively
and
all client code should have been modified
On Fri, Jan 11, 2013 at 3:04 AM, Werner LEMBERG w...@gnu.org wrote:
Patch attached. Werner, feel like committing this?
Not yet, sorry. IMHO the first step for the next release is to
comment out the line
#define FT_CONFIG_OPTION_OLD_INTERNALS
in `ftoption.h' so that the old
On 13-01-11 02:02 AM, Werner LEMBERG wrote:
Not yet, sorry. IMHO the first step for the next release is to
comment out the line
#define FT_CONFIG_OPTION_OLD_INTERNALS
in `ftoption.h' so that the old internals are still available but no
longer activated by default. I've done that right
On 13-01-11 11:55 PM, Werner LEMBERG wrote:
I'll go redo my patches for both versions of the code...
Sorry for that, but looking around what other packages do this seems
to be the most sensible way.
BTW, what patches are you talking about?
Adding a few new bitmap formats. Will send out
On 13-01-12 01:45 AM, Werner LEMBERG wrote:
From: Behdad Esfahbod beh...@behdad.org
Subject: Re: [ft-devel] ttsbit.c vs ttsbit0.c
Date: Sat, 12 Jan 2013 01:36:48 -0600
On 13-01-11 02:02 AM, Werner LEMBERG wrote:
Not yet, sorry. IMHO the first step for the next release is to
comment out
On 13-01-12 02:24 AM, Werner LEMBERG wrote:
I see:
commit 3af607b07d8ac4014c2d6be93ac518a349500dc4
Author: Werner Lemberg w...@gnu.org
Date: Sun Nov 4 17:25:29 2012 +0100
Improve documentation of Unicode IVS handling.
Did you git-push?
Uh, oh... What repository are you using?
On 13-01-17 02:13 AM, Werner LEMBERG wrote:
Guys, I'm not a hardcore C coder, and don't know about private RAM
allocation per-process, and how that's impacted by putting structs
inside of .c files instead of .h files. Of course, I'm willing to
understand why that's the case, I just don't
On 13-01-17 11:03 PM, Dmitry Timoshkov wrote:
Behdad Esfahbod beh...@behdad.org wrote:
Guys, I'm not a hardcore C coder, and don't know about private RAM
allocation per-process, and how that's impacted by putting structs
inside of .c files instead of .h files. Of course, I'm willing
On 13-01-18 03:15 AM, Dmitry Timoshkov wrote:
I'd argue that this document is hightly gcc/ELF/Linux specific, and may not
apply to other platforms, so it can't be considered or even recommended as
a general set of rules for a programmer, especially since Freetype is a
library that's used on
What's the difference between FT_THROW and FT_ERR?
Why no FT_THROW here:
-error = FT_Err_Invalid_Argument;
+error = FT_ERR( Invalid_Argument );
Confused.
behdad
On 13-03-15 03:21 AM, Behdad Esfahbod wrote:
On 13-03-15 03:18 AM, Werner LEMBERG wrote:
Doesn't
On 13-04-22 01:47 AM, Werner LEMBERG wrote:
To all who are annoyed by merging problems with ChangeLog files,
please read the following link:
http://gnu.wildebeest.org/blog/mjw/2012/03/16/automagically-merging-changelog-files-with-mercurial-or-git/
It works like a charm :-)
Why not
On 13-05-03 05:47 AM, Werner LEMBERG wrote:
Yes, I think so. BTW, does `make devel' really works out of the box
on your 64bit platform? I suppose that you have
UINT_MAX = ULONG_MAX = 2^64 - 1
On most 64 bit platforms int is still 32 bit.
--
behdad
http://behdad.org/
On 13-05-04 01:09 PM, Werner LEMBERG wrote:
I've just discovered this:
http://code.google.com/p/mactype/
No idea how it works since I don't use Windows, but it looks
interesting. :-)
There's also:
http://code.google.com/p/gdipp/
--
behdad
http://behdad.org/
On 13-05-16 01:52 AM, Werner LEMBERG wrote:
I'm completely clueless, and I can't find a problem. Does anyone else
see this?
AFAIU this was a Fedora packaging problem that has since been fixed.
https://bugzilla.redhat.com/show_bug.cgi?id=961855
--
behdad
http://behdad.org/
diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index 7d32e83..efb7c12 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -8135,6 +8135,7 @@
TT_RunIns( TT_ExecContext exc )
{
FT_Long ins_counter = 0; /* executed instructions counter */
+FT_UShort
Attached. One of the is the one I also attached to the Savannah bug last week.
--
behdad
http://behdad.org/
From 05bbc23228e00780946a77b4511e25f9008f0d0d Mon Sep 17 00:00:00 2001
From: Behdad Esfahbod beh...@behdad.org
Date: Wed, 3 Jul 2013 12:11:48 -0600
Subject: [PATCH 1/3] Fix BGRA blending
On 13-07-16 08:27 AM, Luiz Henrique de Figueiredo wrote:
At two places in FT_Outline_Decompose there is a division by 2 that
loses one bit of precision. A client walking manually through the
contours of a glyph and mapping the control points to floats by
dividing by 64 and then doing any
On 13-07-16 09:35 AM, Werner LEMBERG wrote:
At two places in FT_Outline_Decompose there is a division by 2 that
loses one bit of precision. [...]
I was doing some tests generating outlines of fonts and come upon
this because the .eps I generated were slightly different but gave
apparently
Hi Werner,
Thanks for pushing out my 'sbix' patch. I'm attaching a small patch of
followup fixes. With these I can use 'sbix' fonts normally.
Cheers,
--
behdad
http://behdad.org/
From a1312ad308ebec6b77672b8cccb92c6e18cb405b Mon Sep 17 00:00:00 2001
From: Behdad Esfahbod beh...@behdad.org
On 13-07-19 08:29 AM, Werner LEMBERG wrote:
Thanks for pushing out my 'sbix' patch. I'm attaching a small patch
of followup fixes. With these I can use 'sbix' fonts normally.
Applied, thanks.
Thanks. One last fix. Apparently USHORT version numbers are to be considered
minor. As such:
Patch attached.
--
behdad
http://behdad.org/
From fe1c90c79a6070bda504c150aedfce63e75053f6 Mon Sep 17 00:00:00 2001
From: Behdad Esfahbod beh...@behdad.org
Date: Mon, 22 Jul 2013 13:46:05 -0400
Subject: [PATCH] Add FT_FACE_FLAG_COLOR and FT_HAS_COLOR
---
include/freetype/freetype.h
On 13-07-25 04:01 AM, Werner LEMBERG wrote:
Patch attached.
Applied, thanks.
Thanks. Did you forget to push out maybe?
--
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Werner,
Please apply this minor patch:
diff --git a/src/base/ftbitmap.c b/src/base/ftbitmap.c
index 975818e..fb09e00 100644
--- a/src/base/ftbitmap.c
+++ b/src/base/ftbitmap.c
@@ -384,6 +384,9 @@
FT_Long r = bgra[2];
FT_Long l;
+/* Short-circuit transparent color to avoid
On 13-08-29 12:06 PM, Werner LEMBERG wrote:
One more iteration, fixing a possible crash with .pcf.gz fonts.
I've now added WOFF support to the git repository. Note, however,
that your patch hasn't worked at all for me; it took me some hours to
make it run. Has the patch *really* ever
On 13-08-29 01:34 PM, Werner LEMBERG wrote:
It also crashed if the compressed font was an OTF instead of a TTF.
Interesting. I checked the code but didn't see what you changed.
`stream' was changed within `open_face' but not updated in the caller.
If the font is not a TTF, the next font
On 13-09-15 08:26 AM, Miles Bader wrote:
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
On 13-09-15 05:06 AM, Werner LEMBERG wrote:
I will soon need the HarfBuzz library which doesn't provide a
`harfbuzz-config' script.
That would be for GSUB closure I assume?
This will be tricky since it will cause a circular dependency between harfbuzz
and freetype. Let me think about it a
On 13-09-17 07:14 AM, Khaled Hosny wrote:
On Tue, Sep 17, 2013 at 07:58:27AM +0200, Werner LEMBERG wrote:
I will soon need the HarfBuzz library which doesn't provide a
`harfbuzz-config' script.
That would be for GSUB closure I assume?
Yep.
This will be tricky since it will cause a
On 13-09-17 03:56 AM, John Tytgat wrote:
On 9/17/2013 8:50 AM, Miles Bader wrote:
2013/9/17 Behdad Esfahbod beh...@behdad.org:
It also used to the case that pkg-config didn't handle
cross-compilation properly (I haven't checked this in a while), which
seems like it would be an issue
This patch is needed, otherwise y-bearing will be wrong and glyphs will be cut
off in applications that use the y-bearing.
diff --git a/src/base/ftsynth.c b/src/base/ftsynth.c
index 241d37f..1d01247 100644
--- a/src/base/ftsynth.c
+++ b/src/base/ftsynth.c
@@ -143,6 +143,7 @@
What's the difference?
--
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Hi,
Lets say ${includedir} is /usr/include. Currently FreeType installs most
headers under ${includedir}/freetype2, but installs ft2build.h under
${includedir}. As such the freetype2.pc has -I directives for both locations.
This normally works, except that the -I${includedir} part defeats the
http://typedrawers.com/discussion/470/new-microsoft-size-specific-design-selection-mechanism
Would be nice to add support for this. I like to use it in fontconfig.
--
behdad
http://behdad.org/
___
Freetype-devel mailing list
On 13-10-22 10:31 PM, Werner LEMBERG wrote:
http://typedrawers.com/discussion/470/new-microsoft-size-specific-design-selection-mechanism
Would be nice to add support for this. I like to use it in
fontconfig.
Thanks for the link. The changes are trivial, however I hesitate to
simply
On 13-10-27 07:26 AM, Werner LEMBERG wrote:
What do you recommend?
Just add.
OK. The stuff is now in the git repository. Please test.
Thanks. We'll go ahead and test this with fontconfig.
Nit: places that say only version X tables really mean version X and higher.
--
behdad
On 13-10-27 08:55 PM, Behdad Esfahbod wrote:
On 13-10-27 07:26 AM, Werner LEMBERG wrote:
What do you recommend?
Just add.
OK. The stuff is now in the git repository. Please test.
Thanks. We'll go ahead and test this with fontconfig.
Nit: places that say only version X tables really
On 13-10-27 09:14 PM, Khaled Hosny wrote:
On Tue, Oct 22, 2013 at 04:59:43PM +0200, Behdad Esfahbod wrote:
http://typedrawers.com/discussion/470/new-microsoft-size-specific-design-selection-mechanism
Would be nice to add support for this. I like to use it in fontconfig.
I think something
You are on your own re implementing FT_Face caching on PangoFT2 fontmaps. If
you come up with a cache, I'll consider upstreaming it.
behdad
On 13-10-29 04:45 AM, Parth Kanungo wrote:
Hello all,
I observed that in pangoft2, the file descriptor opened for the font file,
does not get
On 13-11-08 05:55 AM, Himanshu Joshi wrote:
Hi,
Harfbuzz was used by Android from start as harfbuzz is the base complex
rendering (OTF supporting) engine and also used in Webkit as well.
Right. The old HarfBuzz didn't have swash enabled by default IIRC.
With KitKat
I think Andorid is
On 13-11-23 03:23 AM, Werner LEMBERG wrote:
Toshiya-san,
thanks for your analysis. I wasn't aware of this situation.
I'm questionable which is more forthcoming; the disappear of ILP32
or the inflation of font filesize greater than 2GB. When FreeType3
is planned, of course I will
I have wanted to reply to this, but proper reply is very lengthy so it has
been sitting in my inbox. And now I truly regret not having replied before
you made the release.
On 13-11-13 03:19 AM, Werner LEMBERG wrote:
I like to suggest that ft2build.h be moved inside
${includedir}/freetype2
On 13-11-25 05:21 PM, Werner LEMBERG wrote:
This large patch changes the header file directory layout from
`include/freetype/...' to `include/...', effectively removing
This is actually more problematic. :( Basically you have undone what
I was suggesting. What I was suggesting was to
On 13-11-25 05:28 PM, Werner LEMBERG wrote:
Basically what I want is that the output of the following command:
$ PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --cflags freetype2
should NOT have /usr/include in it. Currently I get:
-I/usr/include/freetype2 -I/usr/include
Any way you can
to use
for the same. I was using it on Windows to make one demo application, will
add libPNG to windows project and try your suggestions.
On Sat, Nov 30, 2013 at 1:15 AM, Behdad Esfahbod beh...@behdad.org
mailto:beh...@behdad.org wrote:
On 13-11-29 04:35 AM, Himanshu
On 13-12-05 05:53 PM, Nigel Tao wrote:
I'm working on a Freetype port to the Go programming language.
I'm curious. Why?
--
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
On 13-12-22 01:19 AM, Werner LEMBERG wrote:
[...]
Wouldn't something like this makes sense also?
Not yet, since...
The only reason not to is for systems that don't have pkg-config. But I
wouldn't worry about those.
In a way this makes freetype-config cross-compile aware, this
GLyphy is an experiment in high-quality glyph rendering using OpenGL ES2
shaders. It's a project of mine at Google that I never really publicly
announced, even though it was briefly mentioned on this list before.
I worked on it mostly in 2011 and 2012. The work was then stalled when I
refocused
On 14-01-15 12:31 AM, octoploid wrote:
14.01.2014, 17:16, Behdad Esfahbod beh...@behdad.org:
GLyphy is an experiment in high-quality glyph rendering using OpenGL ES2
shaders. It's a project of mine at Google that I never really publicly
announced, even though it was briefly mentioned
On 14-01-04 04:16 AM, Werner LEMBERG wrote:
after intensive work in the last few weeks I can proudly announce that
the auto-hinter has been enhanced to access OpenType features using
the HarfBuzz library.
Amazing work Werner. Thanks!
HarfBuzz support, however, is only available in `devel
Hi,
Does anyone have a spec for the Apple dfont format? I like to implement it
natively in HarfBuzz and so far I find the FreeType source code the only
available documentation.
Thanks,
--
behdad
http://behdad.org/
___
Freetype-devel mailing list
On 14-06-03 09:50 AM, 近月丨玉灬 wrote:
Hi there,
All the ttfs in my computer, as well as those Korean/Japanese ttfs I
downloaded, don't have the format 2 cmap. Can any one give me some sample TTFs
for testing? Thanks.
Try UnDinaruBold.ttf
--
behdad
http://behdad.org/
On 14-06-18 01:05 AM, Werner LEMBERG wrote:
It's not *that* mysterious! The code looks like this.
bool flag = 0;
while {
int a;
...
if (flag)
a = 1;
else
a = 0;
...
flag = 1;
}
It doesn't. It looks like this:
while {
int
On 14-07-04 06:12 AM, Werner LEMBERG wrote:
Well, at the same time it reduces the available range for `c' by
more than 50%.
I was greedy with the space for a and b. With a + b 2*46340
instead, c can use the same old limit. We can expand c a lot further
by making a+b only a bit smaller.
On 14-07-04 01:57 PM, Werner LEMBERG wrote:
Well, at the same time it reduces the available range for `c' by
more than 50%.
I was greedy with the space for a and b. With a + b 2*46340
instead, c can use the same old limit. We can expand c a lot further
by making a+b only a bit smaller.
On 14-07-04 03:09 PM, Alexei Podtelezhnikov wrote:
You force me to think, man. To avoid any overflow it is sufficient to satisfy
this inequality
a + b 2 * sqrt(X - c/2)
where X is 2^31 - 1. Using Taylor series it can replaces with a *stronger*
inequality
a + b 2 * sqrt(X) - c /
On 14-07-04 03:59 PM, Alexei Podtelezhnikov wrote:
On Fri, Jul 4, 2014 at 3:30 PM, Behdad Esfahbod beh...@behdad.org
mailto:beh...@behdad.org wrote:
On 14-07-04 03:09 PM, Alexei Podtelezhnikov wrote:
You force me to think, man. To avoid any overflow it is sufficient
On 14-07-07 03:01 PM, Alexei Podtelezhnikov wrote:
Hi all,
Many architectures have special instructions for the most significant
bit: BSR on x86, CLZ on ARM. Some compilers have builtin functions for
that too: __builtin_clz in gcc, _BitScanReverse in VC2005 and up. What
would be a preferred
Werner,
Any chance you would have time to check this out:
https://code.google.com/p/noto/issues/detail?id=33
Thanks!
--
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hi,
I noticed that fontconfig caching (eg, running fc-query on font files) is five
times slower with Adobe CFF engine that it is with old engine. Fontconfig
loads all glyphs with FT_Load_Glyph().
With old engine:
behdad:source-han-sans 0$ time fc-query *.otf --format
This commit:
commit 177982e933ed6f2ab96163e14f4267f8abe89efd
Author: Alexei Podtelezhnikov apodt...@gmail.com
Date: Tue Jul 15 23:54:34 2014 -0400
* src/base/ftcalc.c (FT_MSB): Utilize gcc builtins.
introduced undefined behavior, since __builtin_clz and __builtin_ctz have
undefined
On 14-08-09 04:08 AM, Zoltán Herczeg wrote:
Hi,
I am Zoltan Herczeg, the developer of the sljit JIT compiler. I am new to
FreeType, but if I understand correctly TrueType hinting is done by a
byte-code interpreter (ttinterp). My question is, is it worth to accelerate
this process by JIT?
On 14-08-11 10:15 AM, Alexei Podtelezhnikov wrote: On Fri, Aug 8, 2014 at
4:56 PM, Behdad Esfahbod beh...@behdad.org wrote:
commit 177982e933ed6f2ab96163e14f4267f8abe89efd
Seriously though, my commit does not change much, both FT_MSB and
ft_highpow2 used to return nonsense on zero input even
On 14-08-11 03:12 AM, Zoltán Herczeg wrote:
I suspect hinting can be done parallelly.
Not for an individual glyph.
Multiple glyphs *can* be hinted in parallel, but at that point there's nothing
specific about hinting: multiple glyphs can be loaded in parallel. Except
that FT_Face and
On 14-08-11 02:13 PM, Alexei Podtelezhnikov wrote:
On Mon, Aug 11, 2014 at 11:55 AM, Behdad Esfahbod beh...@behdad.org wrote:
On 14-08-11 10:15 AM, Alexei Podtelezhnikov wrote: On Fri, Aug 8, 2014 at
4:56 PM, Behdad Esfahbod beh...@behdad.org wrote:
commit
On 14-08-12 11:28 PM, Alexei Podtelezhnikov wrote:
Ok. I still do not think that we should fix the macro, because there
is no good value to return. Returning zero for zero is bad too. One
should not call MSB or the builtins with zero argument, just like one
should not divide by zero. So I'll
On 14-08-16 02:06 PM, Behdad Esfahbod wrote:
The 1048576 would have been quite enough for common cases 20 years ago
(that's 16px in 16.16), but not anymore, so the improvement should address
most common usage these days (eg on Android).
Scratch this part. the existing limit is more than
On 14-08-16 07:25 PM, Alexei Podtelezhnikov wrote:
On Sat, Aug 16, 2014 at 2:08 PM, Behdad Esfahbod beh...@behdad.org wrote:
Scratch this part. the existing limit is more than enough for all practical
purposes. It's pixel-size divided by upem in 16.16. So you need a font size
1 pixels
It's fairly easy to do using git.
--
behdad
http://behdad.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
On 14-08-18 01:39 PM, Werner LEMBERG wrote:
It's fairly easy to do using git.
We split it intentionally many years ago. Admittedly, I know longer
know the reason...
Ok I can think of one myself. It's a problem in other projects too.
Having them separate makes it easier to run a newer
I was checking it out today and noticed that there are two main loops: default
big switch, and non-default function-dispatch array. There was also two modes
for the execution context: default MT-safe, non-default MT-unsafe.
I removed the non-default codepaths. And did some removing macros.
I wrote this patch a while ago, to allow overriding CFF stem darkening at
compile time using a custom macro. You might want to take it in.
--
behdad
http://behdad.org/
diff --git a/src/cff/cffobjs.c b/src/cff/cffobjs.c
index cac4ac2..be75149 100644
--- a/src/cff/cffobjs.c
+++
On 14-10-14 07:11 AM, Alexei Podtelezhnikov wrote:
+1 if you preserve English descriptions and stack specs.
Check again. I cleaned it up some more, and all instruction implementations
in the switch are limited to two lines now.
--
behdad
http://behdad.org/
On 14-10-14 10:17 PM, Werner LEMBERG wrote:
+1 if you preserve English descriptions and stack specs.
Yeah, this is a good thing. Thanks for the reminder.
Check again. I cleaned it up some more, and all instruction
implementations in the switch are limited to two lines now.
Mhmm, we
On 14-10-14 11:25 PM, Werner LEMBERG wrote:
Which other ones do you want documented? I don't see any value in
documenting, eg, these, as they are very self-documenting:
Mhmm. Just for consistency, I would like to have
Hi,
It was reported to me by my colleague Doug Felt (CC'ed) that FT_MulFix takes
FT_Long parameters as defined in freetype.h, but several inline
implementations of it in ftcalc.h take FT_Int32 arguments. I imagine this
might have historical reasons, but it's something that would be good to
On 14-11-18 09:32 PM, Werner LEMBERG wrote:
I was also wondering if FT_Long should be defined synonymous to
FT_Int32, etc.
typedef FT_Long FT_Int32
Hmm. FT_Int32 is *exactly* 32bit, while FT_Long is simply a typedef
to `long' and thus *at least* 32bit, depending on the compiler
Hi,
While updating our internal version of FreeType, we noticed some line height
and rasterization changes, which we tracked down to this commit:
b0962ac34e66052ccfee7996e5468f30d4bd5a72 is the first bad commit
commit b0962ac34e66052ccfee7996e5468f30d4bd5a72
Author: Steven Chu
On 14-11-26 08:58 PM, Werner LEMBERG wrote:
Essentially it's about whether FreeType should respect bit 3 of
head-table flags:
http://www.microsoft.com/typography/otspec/head.htm
and implemented here:
https://github.com/behdad/freetype/blob/master/src/truetype/ttobjs.c#L1189
I don't
On 14-12-07 02:31 AM, Werner LEMBERG wrote:
And please don't answer with `longjmp is evil'...
But that *is* what's going on! Looks like longjmp might be being called
before setjmp being called.
I've also attached `Roboto-Thin.ttf', together with the output of
valgrind (current SVN
On 14-12-07 10:20 PM, Werner LEMBERG wrote:
I highly suggest you remove ftvalid (and gxvalid).
They are not used in a default build.
It's unused, which makes it untested, and as such broken.
`Not in the default build ' means `broken'? You are exaggerating.
Oh no, I mean unused by widely
On 14-12-07 10:20 PM, Werner LEMBERG wrote:
I highly suggest you remove ftvalid (and gxvalid).
They are not used in a default build.
It's unused, which makes it untested, and as such broken.
`Not in the default build ' means `broken'? You are exaggerating.
Oh no, I mean unused by widely
On 14-12-02 04:25 PM, Behdad Esfahbod wrote:
On 14-11-26 08:58 PM, Werner LEMBERG wrote:
Essentially it's about whether FreeType should respect bit 3 of
head-table flags:
http://www.microsoft.com/typography/otspec/head.htm
and implemented here:
https://github.com/behdad/freetype/blob
On 14-12-09 08:50 PM, Werner LEMBERG wrote:
for example, invalid glyph IDs are a perfectly valid use in GSUB as
intermediate values. Currently ftvalid downright rejects those.
Fair point. Do you have a test font for this issue?
Not off the top of my head.
--
behdad
http://behdad.org/
On 14-10-26 06:06 PM, Behdad Esfahbod wrote:
On 14-10-17 10:59 PM, Werner LEMBERG wrote:
I don't think I'd have time to fixup the rest soon. If someone
wants to continue that would be nice. I personally find the six
lines of comments per four lines of code+whitespace too distracting
with a FreeType
including the patchset.
Thanks!
Behdad Esfahbod
30 December 2014
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
On 14-12-30 04:06 PM, Behdad Esfahbod wrote:
The patchset mainly removes use of singleton buffers in favor of stack or
per-face allocated ones. In all cases this has no down side. The exception
is the patch that affects the autohinter, which results in significant (~20%)
slowdown. I plan
On 14-12-31 02:29 AM, Werner LEMBERG wrote:
I guess it is no longer of importance that we have two implementations
– within the last 10 years compilers have certainly improved... And
noone on the list objected either so I suppose that it is safe to
simply remove the stuff to make the code
101 - 200 of 479 matches
Mail list logo
