, and used FreeType to achieve that.
Thanks to David Turner and Werner Lemberg and everyone else for creating
and improving FreeType over so many years.
Best wishes,
Graham
--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
-70 in
raster.rs)
let x0floor = x0.floor();
let x0i = x0floor as i32;
don't appear to prevent x0floor or x0i from being negative.
- Graham
On 19/08/2016 14:33, Graham Asher wrote:
Right now I think the supposed bug doesn't exist, but was caused by
forcibly closing a debug session in Vis
Right now I think the supposed bug doesn't exist, but was caused by
forcibly closing a debug session in Visual Studio 2015.
On 19/08/2016 14:02, Graham Asher wrote:
I've fixed the clipping and winding rule bugs, and it now works well
with CartoType map rendering, and seems fast although I have
; no doubt that is my fault. I will try to reproduce and fix it.
I have uploaded the new version.
On 19/08/2016 11:16, Graham Asher wrote:
New version uploaded at
http://www.cartotype.com/assets/downloads/raster_fp/
which is going to be its home for now.
More news when I have done some more
New version uploaded at
http://www.cartotype.com/assets/downloads/raster_fp/
which is going to be its home for now.
More news when I have done some more testing.
On 19/08/2016 09:27, Graham Asher wrote:
This isn't the final version; as always, after releasing a piece of
code into the wild
AM, "Graham Asher" <graham.as...@cartotype.com
<mailto:graham.as...@cartotype.com>> wrote:
Hi Werner,
yes, I e-mailed him yesterday, and asked a question about his code
too, but with no great hope of an early reply, knowing he's busy.
I asked him why his co
Hi Werner,
yes, I e-mailed him yesterday, and asked a question about his code too,
but with no great hope of an early reply, knowing he's busy. I asked him
why his code to handle quadratic splines used a division into a number
of evenly spaced values for the t parameter rather than recursive
I'd forgotten about that! I was the other person.
On 05/08/2016 09:21, Ken Sharp wrote:
Personally, as one of the two people who did a load of work to get
FreeType integrated into Ghostscript
--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
equivalent. If this
works reliably, I could imagine to have both a Rust source file and
its translation in the FreeType git repository. Unfortunately,
`crust' needs a huuuge set of preliminaries...
Werner
--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0
Not this century.
On 06/07/2016 10:37, Hin-Tak Leung wrote:
Do people still care about restricting to the convention of 8.3 file names?
--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
___
Freetype-devel
Please consider calling it ftdiagnostics.h, which is more explanatory.
To my native-English-speaking mind, 'diag' looks as if it stands for
'diagonal' or 'diagram'.
I think the enumeration values should be FT_DIAGNOSTIC_XXX too.
Sometimes it's a good idea to spell things out.
- Graham
On
to maintain support for VS2008, which a lot of people used for
five or six years.
- Graham
On 07/03/2016 13:00, John Tytgat wrote:
On 3/7/2016 11:42 AM, Graham Asher wrote:
I don' think it's necessary to support VS2013. It was buggy and
incomplete compared to VS2015, which is much better.
That's
.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
On 06/12/2015 15:19, Nikolaus Waxweiler wrote:
The autohinter has a new toggable stem darkening property
A couple of typos:
"The autohinter has a new toggable stem darkening property": The word
'toggable' doesn't exist. I think you mean 'toggleable' (although that
is not the happiest of
* to the
desired pointer type in a couple of places, and (in zlib) changing
old-style C function declarations to the current C and C++ syntax.
I hope all this is of interest.
Best regards,
Graham
--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
I very much doubt this does any harm; modern compilers will do the right
thing. It won't do any harm to get rid of the L suffixes, but it is
unlikely to make any difference at all to compiled size or performance
on any platforms that matter.
Best regards,
Graham
On 24/06/2015 17:24, suzuki
Sai,
you need to cache glyphs in some way; performance is not usually good
enough to create glyphs on demand and throw them away. FreeType has a
glyph caching system:
http://www.freetype.org/freetype2/docs/reference/ft2-cache_subsystem.html.
Best regards,
Graham Asher
On 17/10/2014 09:39
the code changes I made, and cannot give any support or further
information. But knowing that something is possible can be encouraging.
- Graham Asher
On 16/05/2014 06:44, Werner LEMBERG wrote:
I'll use freetype support C++/CLI as .net wrapper and in C# project
reference it, but not depend
Be sure to use the Unicode codepoint U+20A0, not the non-Unicode
codepoint 0x80 used in Windows codepages.
On 04/04/2014 14:48, suzuki toshiya wrote:
Hi,
If you see all glyphs in the font by ftview,
could you find euro sign in your Arial?
Regards,
mpsuzuki
On 04/04/2014 04:17 PM, Ashutosh
. That was impossible because (I believe) I had
not removed dependencies on native run-time libraries; and now the task
has been rendered unnecessary by the release of Windows Phone 8, which
supports native C or C++.
Graham Asher
CartoType Ltd.
On 13/11/2012 08:12, Werner LEMBERG wrote:
I
,
FT_PIXEL_MODE_MONO,
FT_PIXEL_MODE_GRAY,
FT_PIXEL_MODE_GRAY2,
FT_PIXEL_MODE_GRAY4,
FT_PIXEL_MODE_LCD,
FT_PIXEL_MODE_LCD_V,
*FT_PIXEL_MODE_ARGB_PRE,
FT_PIXEL_MODE_ARGB_PRE_PALETTE,
*FT_PIXEL_MODE_MAX /* do not remove */
} FT_Pixel_Mode;
Best regards,
Graham
Well, what I'm suggesting is just adding these constants, which is a 5
minute patch. I'm not allowed to release my client's bitmap font format
(which I invented) into the wild. It would be nice to have a standard
coloured-bitmap font format but it would probably not be a good idea for
me to
I have asked my client whether they will consider allowing me to make
their bitmap font format public-domain so that someone can write a clean
FreeType driver for it. I have a driver for it but it's not 'clean': it
depends on a huge amount of other proprietary stuff. We would also need
a clean
.
Best regards,
Graham Asher
CartoType Ltd.
On 14/04/2012 17:19, Vinnie wrote:
From: Alan Coopersmithalan.coopersm...@oracle.com
Do you know where most of the FreeType security issues in the past few years
has been found? By people trying to hack smartphones via downloads of
malicious
I know this isn't a welcome remark, but I'm going to say it anyway, because
it's a rule I apply to myself: if an API is difficult to explain then it should
be changed. Yes, I know you can't do that - but it's an argument for carefully
documenting something as it is written, and changing it
Vivek,
in fact the great work is David's, not mine - I made the original
attempt, which was buggy, and then supplied a fix, but David wrote a new
version which was justified mathematically and based on Hain's paper, as
you mention. So I'll have to pass the responsibility for explaining it
to
All the 2.4.6 files on the savannah site give 404 errors :-(
On 29/07/2011 05:52, Werner LEMBERG wrote:
FreeType 2.4.6 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also
Thank you. I know. I was reporting an error on the savannah site, which
ought to work as advertised.
On 29/07/2011 09:40, İsmail Dönmez wrote:
Use sourceforge. It works.
On Fri, Jul 29, 2011 at 10:38 AM, Graham Asher
graham.as...@cartotype.com mailto:graham.as...@cartotype.com wrote
for increasing performance, since I'm
working on the code at the moment.
Do you have any view on handling the miter limit?
I will implement option 4 below unless I receive feedback in favour of a
different approach.
Thanks.
David %^
From: Graham Asher
the outer border
is clockwise and the inner is anti-clockwise; for correct filling, the
outer should be anti-clockwise and the inner clockwise.
That's based on a slightly out-of-date version, so forgive me if it's
been fixed.
Graham Asher
CartoType Ltd
On 27/06/2011 16:05, David Bevan
I have discovered some other minor optimisations to the stroker module,
but I'm not sure if it's worth mentioning them - they won't provide much
speed improvement but will get rid of some anomalies and inefficiencies.
I've been experimenting with a modified version of the stroker in
CartoType,
The data member FT_StrokerRec::valid does not seem to be used. I
therefore recommend that it is removed.
Best regards,
Graham
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
(as Werner said).
Graham Asher
CartoType Ltd.
- Original Message
From: Werner LEMBERG w...@gnu.org
To: jkl...@leadwerks.com
Cc: freetype-devel@nongnu.org
Sent: Monday, 20 December, 2010 9:33:31
Subject: Re: [ft-devel] FreeType 2 for OSX
Where can I find complete documentation on how
Aleksei,
you really shouldn't be annoyed. My earlier patch was shown to be inferior to
David Bevan's, and I was obliged to accept the fact. The only possible criteria
are objective ones: does it work? is it faster? is it simpler? I believe David
has shown using objective arguments that the
There is no gain or loss in speed and the quality is the same
In that case the patch should not be applied. Any change but the very simplest
has some risk. Risk should only be undergone if there is demonstrable benefit.
Graham
- Original Message
From: Алексей Подтележников
Please give evidence of ugliness in the form of images, preferable in sets of
three: (i) before the patch from David Bevan and myself; (ii) using the current
version of FreeType; (iii) using your suggested patch.
Thanks,
Graham
- Original Message
From: Алексей Подтележников
I am sorry to say that I regard a 3% slowdown as intolerable, especially for my
purposes. I haven't noticed any quality problems with the existing code. We can
define quality as the inverse of the maximum distance of the generated line
segments from the actual curve; that can be adjusted using
Alexei,
I don't have much time or energy for this at the moment - sorry. Of course I
will be looking at it again, but I believe that the solution hammered out by
David Bevan and myself is a good one - it solves the bug I introduced while
retaining the speed increases I first made the changes
I guess my version has PIXEL_BITS = 6. Sorry, didn't notice the discrepancy.
Yes, FT_MAX_CURVE_DEVIATIO ought to be defined so that it's always 1/4 of a
pixel.
Graham
- Original Message
From: Алексей Подтележников apodt...@gmail.com
To: GRAHAM ASHER graham.as...@btinternet.com
Cc
Alexi,
I think it's a good idea if you can benchmark the code to see if the
extra arithmetic results in any speed improvement. I suspect it might
slow things down slightly for ordinary glyphs which always fit in a
single band, but there's a chance it might help at high resolutions
where
Here is a third and I hope final version of the spline flattening
patch, incorporating the latest version of David Bevan's cubic spline
flattening routine.
Notes:
1. As with the previous versions, it solves the bug in flattening
s-shaped curves (cubic with control points on both sides of
Symbian and RIM OS also use FreeType for rendering fonts on displays. I know
because I put it there :-)
Graham
- Original Message
From: Werner LEMBERG w...@gnu.org
To: djko...@aol.com
Cc: freetype-annou...@nongnu.org; freet...@nongnu.org; freetype-devel@nongnu.org
Sent: Tuesday, 14
David,
I've tested your code with CartoType, my map rendering library, and it
produces a small speedup there too. (The smallness of the speedup is to
do with the fact that CartoType's curves are nearly always
approximations to arcs of circles, which don't behave too badly with my
previous
No, forget that, I was getting confused.
Graham
On 12/09/2010 11:16, Graham Asher wrote:
On 08/09/2010 08:50, David Bevan wrote:
if (s (s_limit = L * (TPos)(FT_MAX_CURVE_DEVIATION / 0.75)))
goto Split;
Surely this should be
if (s (s_limit = L * (TPos
, or a mixture
of both?
Best regards,
Graham
- Original Message
From: David Bevan david.be...@pb.com
To: Graham Asher graham.as...@btinternet.com
Cc: freetype-devel freetype-devel@nongnu.org
Sent: Tuesday, 7 September, 2010 12:40:21
Subject: RE: [ft-devel] latest patch file for spline
...@pb.com
To: GRAHAM ASHER graham.as...@btinternet.com
Cc: freetype-devel freetype-devel@nongnu.org
Sent: Tuesday, 7 September, 2010 13:52:35
Subject: RE: [ft-devel] latest patch file for spline flattening
After trying various other fonts, I settled on using a single large (14,000
glyphs; 800,000
Have you done an ARM version? Forgive my inattentiveness if you've
already announced one. It just struck me that this sort of optimisation
is even more necessary on mobile devices.
Graham
James Cloos wrote:
The final result for amd64 looks like:
static __inline__ long
FT_MulFix_x86_64(
Here's a new version of my spline flattening patch. (I would like to be
able to push this to the git repository but am having authentication
problems; Werner has been helping me, but no success so far, probably
because of my ineptitude in these matters.).
The nub of the latest change is that
%^
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
Graham Asher
Sent: 6 September 2010 11:10
To: freetype-devel
Subject: [ft-devel] latest patch file for spline flattening
Here's a new version
Here's a patch for review. As you know I have also started the process
of registering as a contributor, so I might be able to commit directly
if you like.
Graham
Werner LEMBERG wrote:
Some brief comments inline.
More feedback from my investigations later. [...]
BTW, thanks a lot to
I have finally got round to installing TortoiseGit on the computer I'm
using for this, and have cloned the repository, so I shall be able to
give you a patch that will fix the bug reported by Stefan (still don't
know his surname) and correct the other bug I noticed - the strange
relaxation of
David Bevan's citation of two papers on spline flattening
(http://www.cis.southalabama.edu/~hain/general/Publications/Bezier/Camera-ready%20CISST02%202.pdf
and
http://www.cis.usouthal.edu/~hain/general/Publications/Bezier/bezier%20cccg04%20paper.pdf)
stimulated some more thoughts on the
-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
GRAHAM ASHER
Sent: 3 September 2010 09:14
To: FreeType
Subject: [ft-devel] more thoughts on cubic spline flattening
David Bevan's citation of two papers on spline
+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
Graham Asher
Sent: 30 August 2010 10:59
To: freetype-devel
Subject: [ft-devel] a satisfactory fix for the cubic spline bug
I thought about this overnight and realised that we can slightly modify
Correction: for we are restricted to a maximum coordinate
size of sqrt(2^31) read we are restricted to a maximum coordinate
size of the cube root of 2^31
- Original Message
From: GRAHAM ASHER graham.as...@btinternet.com
To: David Bevan david.be...@pb.com; freetype-devel freetype-devel
, for which the midpoint of the curve, as defined by bisection, is not
the
point of maximum deviation.
Best regards,
Graham
From: David Bevan david.be...@pb.com
To: GRAHAM ASHER graham.as...@btinternet.com; freetype-devel
freetype-devel@nongnu.org
Sent: Tuesday
And putting this equation into more standard quadratic form I get
d_norm(v) = 0.072(v^2) + 0.229v + 0.449
which yields 0.75 as expected for v = 1, so it looks as though I have the right
equation here.
Graham
From: GRAHAM ASHER graham.as...@btinternet.com
The aim is to draw a straight line between the start end end of a cubic
spline, instead of rendering the curve correctly, if the curve deviates
by less than a certain value from the straight line. The code in
gray_render_cubic in ftgrays.c checks only the midpoint of the curve.
However, this
Correction: it's not monotonicity that matters, but having the two
control points on different sides of the straight line.
Graham Asher wrote:
The aim is to draw a straight line between the start end end of a
cubic spline, instead of rendering the curve correctly, if the curve
deviates
Here's a fix that works. I'm trying to think of a faster way of doing
it. The fix splits the cubic spline in two, guaranteeing that the
resulting curves have their control points on the same side of the
straight lines from start to end, then performs the original test for
the distance (or
to end can be further from the line than the curve's
midpoint as defined by bisection of the curve.
Graham
Graham Asher wrote:
No, in nearly all cases the midpoint is the point on the curve
furthest from the straight line when both control points are on the
same side. It can happen, though. I'm
it's an Adobe Type 1 file or
something like that.
Graham
- Original Message
From: kde...@vogtner.de kde...@vogtner.de
To: Graham Asher graham.as...@btinternet.com
Sent: Tuesday, 24 August, 2010 14:02:34
Subject: render error after ftgrays: Speed up rendering of small cubic
splines
that FreeType's sole purpose is to rasterize glyphs, while mine
is also to rasterize large arbitrary shapes. Nevertheless, these aims tend to
converge as display resolution improves; at modern resolutions of around
200dpi,
18pt glyphs are as large as 50 x 50 pixels.
Graham Asher
CartoType Ltd
Werner,
I've just taken a look at the latest version of ftgrays.c in git, and to my
surprise, it already uses a design which I considered and rejected! I am not
claiming that I was right in rejecting it, though.
It avoids using quicksort by creating a list of cells for each scan line (i.e.,
I think using #ifdefs is a good idea for the moment. Also, there are two
semi-obvious ways to make the optimisation even better, and I want to try to
implement them:
1. Pre-calculate the width of the array, to avoid calculating it in every call
to gray_record_cell.
2. (This is the big one).
I have just noticed that this doesn't work perfectly yet. I am sure the
principle is sound, though. I'll send a revised version as soon as possible.
- Original Message
From: GRAHAM ASHER graham.as...@btinternet.com
To: freetype-devel@nongnu.org
Sent: Monday, 19 July, 2010 16:11:35
My patch affects cubic splines only. TrueType fonts do not use cubic
splines, only quadratics, so any testing should include Adobe Type 1
fonts, which use cubics, and other PostScript font formats that use the
same system for storing outlines. Does this font collection contain any
such fonts?
You're welcome - I see that you had to get rid of a check on the return
value of gray_render_line, which I forgot about. That is there because I
use a modified version of FreeType that can be compiled as pure .NET
intermediate language code; and to do that I had to get rid of setjmp
and
In your image, why are the ligatures anti-aliased, while the main text
is not? Surely you should generate non-anti-aliased glyphs to go with
the non-anti-aliased bitmaps stored in the font file; or, if
anti-aliasing is desired, the stored bitmaps should not be used.
In general, it should not
No, I don't think it's worth worrying about this right now. I worked on
this because I wanted to create a version of my CartoType library as a
portable .NET assembly, and in fact I managed to compile CartoType as
C++/CLI code, which is a tribute to its robustness; but to do that I had
to
Unfortunately not only there but in the rasterizer, if memory serves.
They were not in any place where I could get rid of them easily by
disabling certain features.
Graham
Behdad Esfahbod wrote:
On 06/10/2010 05:17 AM, Graham Asher wrote:
Doing this showed that setjmp and longjmp
Werner,
I think your patch is slightly wrong because you use the same values for
mid_x and mid_y for both the comparison and for drawing; however, one
set if values needs to go through DownScale() and the other through
UpScale(); that's why I calculate separately in my hastily-prepared
Another question arises: why do we divide by ras.conic_level when we are
dealing with cubic splines? Surely it should be
dx= dx / ras.cubic_level;
or (better - we can use assignment operators in FreeType, I think ;-):
dx/= ras.cubic_level;
Graham
Werner LEMBERG wrote:
Calculate
Werner,
here's what I think is a better version of the start of the function.
I've combined a few declarations and initialisations; probably against
your house style, so please adjust as appropriate if you don't like it.
Important changes: (i) dx is now divided by ras.cubic_level; (ii) mid_x
both da and db. Perhaps db
only will suffice. I hope that David or Werner can comment.
Best regards,
Graham Asher
CartoType Ltd
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
* (control1-y + control2-y)) / 8;
dx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
if ( dx 0 )
dx = -dx;
dy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
db = dx;
}
without those multiplications by 3, which crept in again.
Graham
Graham Asher
A finicky compiler told me that the variable
AF_Point first
in af_glyph_hints_reload in afhints.c was unnecessary. This turns out to
be true (but note that there are two separate variables of this name in
the function: we're talking about the first 'first'). It is assigned to
at line 526:
Here's a suggestion to simplify FreeType slightly by removing unused
code. It has the agreeable side effect of preventing a compiler warning
about an unused argument (get_inflections in af_glyph_hints_reload).
1. Remove the function af_glyph_hints_compute_inflections from afhints.c.
2. Remove
of the glyph
(font family, size, transform, emboldening, etc.) and the value is the
glyph. Keep track of the least recently used glyph using a linked list;
or simply rely on hashing, and remove glyphs where a conflict occurs.
Best regards,
Graham Asher
Werner LEMBERG wrote:
We
this one (it's a gotcha
because you have to enable the psnames module both in ft_module.h and by
having the right config option macro defined).
Graham
James Cloos wrote:
Graham == Graham Asher graham.as...@btinternet.com writes:
Graham What we have here is a CFF font packaged
for asking: the answer isn't obvious to me.
Thanks in advance,
Graham Asher
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Thanks - can you tell me which version this support was introduced in? I
am using FreeType 2.3.7, and it doesn't work even though I have enabled
and built the relevant drivers.
Graham
Tor Andersson wrote:
On Fri, Mar 5, 2010 at 2:40 PM, Graham Asher
graham.as...@btinternet.com wrote
Thanks - I'll experiment further. But the addition of the CFF driver is
not sufficient. What we have here is a CFF font packaged inside
something else, I think.
Graham
James Cloos wrote:
Graham == Graham Asher graham.as...@btinternet.com writes:
Graham Thanks - can you tell
Despicable domain squatting and negative advertising. Shame on them.
Graham
Behdad Esfahbod wrote:
Stumbled upon freetype.com by accident. Have people seen this before?
Interesting...
behdad
___
Freetype-devel mailing list
The net effect of consuming one element and adding two is to add one.
The code looks correct to me.
Graham Asher
Ning Dong wrote:
Hi,
I'm checking the cff_decoder_parse_charstrings function in cffgload.c
of FT239.
According to CFF technical note #5177, operator dup should
consume one
I agree - I also have had no problem using custom allocators with
FreeType 2. I have successfully used DlMalloc, and currently use a
hybrid system comprising a fast-access pool of small blocks and a
fallback to standard malloc and free.
Graham Asher
CartoType
Mickey Gabel wrote:
Werner
From a purely personal point of view I welcome a move to git, simply to give
me an incentive to learn git :-)
Graham
-Original Message-
From: freetype-devel-bounces+graham.asher=btinternet@nongnu.org
[mailto:freetype-devel-bounces+graham.asher=btinternet@nongnu.org] On
Behalf Of
I'm sorry to say that there is no chance that I shall work on this again. I
have too much on my plate for the foreseeable future.
But I claim (as always ;-) that the parts of the bridge code I wrote are
relatively easy to follow and can probably be debugged by single-stepping
and thinking hard.
Oh dear - I shouldn't have said anything - sorry, I have no time to deal
with this. All I can say is that if there was a memory leak in FreeType it
would show up in all sorts of places - not just in Symbian OS. I suspect
it's a problem in the calling code.
I recently had heap corruption problems,
Actually here is a better design: at the point of discovery, set a flag in
the FT_Face structure. That way, there is no interference between a non-zero
error code and the opportunity for the caller to ignore the problem.
Graham
-Original Message-
From: Werner LEMBERG [mailto:[EMAIL
, but I'll just put this on
record as a warning.
Callers should check whether face-family_name is null before using it; a
missing family name is likely to be an error although the API doesn't
actually tell us whether it is.
Graham Asher
___
Freetype
-internal-flags FT_GLYPH_OWN_BITMAP )
to
if (slot (slot-internal-flags FT_GLYPH_OWN_BITMAP) )
Best regards,
Graham Asher
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Here's another small problem I found when porting to 2.3.7. There's a
missing 'const' in the declaration of the array tt_post_default_names. It
causes the pointers to be non-const, and that creates 1032 (4 * 258) bytes
of writable static data, which prevents builds from working for several
You're welcome - and I apologise for not noticing this when I moved to
2.3.7. Did you put some variant of my original explanatory comment in? It
might help. Here it is:
/* Adjust underline position from top edge to centre of stroke to convert
TrueType meaning to FreeType meaning. */
Best
However, the logic is correct, is it not? It looks as if the code is
checking whether all of the items in the array fulfil a condition. So it
should be fixed as originally suggested by mpsuzuki, without changing the
logic, but preventing the warning.
Graham
-Original Message-
From:
FreeType is also the font engine in the Symbian and RIM operating systems. I
know, because I put it there. And they are closed-source systems, although I
believe Symbian is moving to open-source. There is no licensing difficulty
as long as the use of FreeType is acknowledged.
Graham Asher
Frank,
I've added some brief answers to your questions below.
Best regards,
Graham
-Original Message-
From: Frank W. Miller [mailto:[EMAIL PROTECTED]
Sent: 07 July 2008 04:59
To: 'Graham Asher'; freetype-devel@nongnu.org
Subject: RE: [ft-devel] Rotated text
Thanks very much
U+00A0 is not a space but a non-break space, so something is wrong here
surely?
Graham Asher
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Sergey Tolstov
Sent: 08 May 2008 07:00
To: freetype-devel@nongnu.org
Subject: [ft-devel] patch for Type1 Unicode
glyph; and by drawing the shadow at lower intensity, etc.
Graham Asher
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of sarathks
Sent: 25 April 2008 12:51
To: freetype-devel@nongnu.org
Subject: [ft-devel] Adding edge effects
Hi
Does any body know how
Sent: 14 December 2007 14:17
To: Graham Asher
Cc: freetype-devel@nongnu.org
Subject: Re: [ft-devel] limiting the heap memory used by a TrueType font
Hi Graham,
first, keep in mind that the 'loca' table, as well as many other ones, are
simply never copied in the heap if the font file is already
1 - 100 of 131 matches
Mail list logo
