FreeType 2.4.9 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
(please read the footnote on this page!)
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the
I don't see the tag for VER-2-4-9...or am I misunderstanding?
Oops! Just pushed :-)
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
You must not use ftview to test whether glyphs are correctly joined!
This programs inserts an additional pixel horizontally between each
glyph. For simple stuff, use ftstring.
Unfortunately, it doesn't support embolding... Patches welcomed :-)
Werner
With patch it is better now, see the attached image.
You must not use ftview to test whether glyphs are correctly
joined! This programs inserts an additional pixel horizontally
between each glyph. For simple stuff, use ftstring. For complex
shaping, you need a demo program from, say,
We are considering using your program “Freetype 2.4.5” in our
products.
Please use the latest release of the FreeType library, 2.4.9, which
contains many security fixes.
You are the author and owner of the copyrights in the program. You
have distributed the program under the attached
Then I would prefer
if (code == 0)
break;
Works for me. See attached.
I was quicker :-) Please resend your patch relative to the current
git.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I was quicker :-) Please resend your patch relative to the current
git.
Here you go.
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Two macros 'sbitset' and 'isdigok' in bdflib.c has recently become
synonymous.
Good catch! Thanks for the patch, I've just applied it to the git
repository.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I want to provide a simple header that users of the amalgamated
version of FreeType can edit to turn modules on and off. For
example, my own application doesn't require anything other than
TrueType font loading, outline extraction, and hinting (no renderers
or other formats needed).
I'm
A testable version of the patch is attached. At the end I decided to
introduce a new interface FT_Outline_EmboldenXY. Comments?
From a quick glance, this looks like a good solution, thanks! I will
have to test and check this more thoroughly, and this will take time I
fear since I'm quite busy
We had report of regression in GTK markups rendering in Ubuntu
precise, (i.e ulabel/u would render underlined), [...]
We have reverted that commit in Ubuntu for now to workaround the
issue but I would like to know how to determine if that's a bug in
freetype or if other part of the stack
Yes. This is what the TrueType standard mandates for bi-level and
grey-level glyphs. Note that ClearType is *not* implemented in
FreeType yet! As soon as this happens, the situation changes.
BTW, section 3.3.2 in the document below gives a nice description of
fractional advance widths and
I agree that my statement is hypothetical -- as was Werner's
assertion that What FreeType now returns is what the font designer
has had in mind while designing the font.
My assertion is not hypothetical! As the goal of FreeType is to be
fully compatible with the MS rasterizer, unexpected
As a way of ping, I going to throw in a much simpler
FT_Outline_Get_Orientation patch. So the whole collection of three
patches now looks like the attached. Comments, suggestions?
Thanks a lot for your work! Everything looks very promising, however,
I don't have time currently to do a deep
Pulled latest source today and built as usual but install fails with
following error; [...]
install: ./ttfautohint.html: No such file or directory
There is a new dependency for building from git: You need pandoc.
http://code.google.com/p/pandoc/downloads/list
Note that the new
I've stumbled upon this paper that claim wavelet rasterization may
give better cell coverage (than freetype):
This is a nice paper, thanks for the link. However, it says that
wavelet rasterization can't compete with specialized rasterizers like
FreeType w.r.t. speed. Additionally, the cell
I support the use of pandoc.
Yeah, it's very nice. It took me some days to evaluate the various
documentation systems: My first thought was to use doxygen, but this
format is not really suited for standalone documentation like a user
guide $(Q#|(B maybe it is, but I haven't found an easy
cd builds/unix; ./configure
/bin/sh: ./configure: Permission denied
Looks like incorrect file permissions. The file
`builds/unix/configure' must be executable.
Try
chmod 755 builds/unix/configure
Werner
___
Freetype-devel mailing list
Just I've checked Adobe Reader 5.0 on Mac OS X 10.3,
it displays the text (as attached picture).
Should I ask Adobe experts about if this is a regression,
or, appropriate behaviour to prevent some vulnerability
issue?
Yes, please do so. Maybe there is some kind of heuristic added to the
I've updated the amalgamated version of FreeType, [...]
Anything which I should take care of?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Alexei,
thanks for working on this; I fear I won't have more time in the near
future to give more thoughts to the problem.
Just a minor remark:
FT_ORIENTATION_NONE is supposed to mean CANNOT BE DETERMINED, which
is easier said than done. Any contour has a well defined orientation
as a sign
A small remark:
- No self-intersection. Now, when one says self-intersecting, one
has to qualify. I was under the impression that assuming outlines
are not self-intersecting was a safe assumption. However, I'm
convinced now that this is absolutely false assumption.
Yep.
I'd say
It competes with freetype-gl really. It's a GPU rasterizer. The
main different with freetype-gl is that I don't do any sampling, so
the glyphs are truly infinitely zoomable.
Nice! No time to look at it more closely, but I've recently skimmed
over a paper which uses wavelet transformation
Today I tested out the TT-instructed Oxygen font from the KDE repo
with my TT subpixel hinting patches. This is the result:
http://www.infinality.net/files/oxygen-infinality-problems.png
This looks like Oxygen has been hinted with an older version of
ttfautohint which was buggy... Current
First though i think we should check that the issue is not with a
particular buggy build of Oxygen;
FYI: Recent versions of ttfautohint add version information and
calling parameters to the `name' table; older ones don't.
Werner
___
I 've sent Erik ttfautohint 0.8 versions of Oxygen to confirm the
problem.
Thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Erik,
thanks for your analysis.
(The main difference between #2 and #3 is that #3 snaps horizontal
stems to pixel boundaries, which normal Freetype slight hinting does
not do. I personally prefer the stems to be snapped to integer
pixels like this. It looks less dirty to me, however
Ok, so i've tested this with a infinality patched freetype 2.4.9 w
Kubuntu. [...]
Obviously a bug w.r.t. Erik's implementation of ClearType's
compatibility mode. I've contacted Greg Hitchcock, asking for
clarification.
Werner
___
Not sure i understand 100%, but isn't it significant that the
infinality patched freetype only renders ttfautohinted fonts in this
way? An infinality patched freetype (bug or not) renders other
instructed truetype fonts perfectly normally afaik.
Well, Erik tries to implement Greg's ClearType
Essentially, it's a generic SDF rasterizer, like freetype-gl is, but
instead of using a 2D sample to represent the SDF, we use
circular-arc splines.
Aah, some time ago I was also interested into this topic (but for
completely different reasons); I've searched the internet and found
some very
There's a build error on Mac OS X (10.7) w/ ttfautohint version 0.8:
for some reason, the `--libtool` argument to freetype-config gives a
path to a nonexistent library. I do think the right argument is
`--libs`. Please find attached patch.
Thanks. I'm not exactly sure whether this is a
Commit 6076a72 seems to have broken ttfautohint's `configure
--with-freetype-config`, attached a little patch to restore it.
Applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Sorry I don't know how to make computing on the terminal iMac (OS
Lion).
You should look up in the Mac OS X documentation how to open a
terminal and how to work in it.
I am building a Font with FontForge and there is missing
instructions table in it.
I don't understand this. If you design
The way I try to read the buffer is by copying the bytes starting at
the memory location of the buffer ranging until glyph.bitmap.width *
glyph.bitmap.rows.
I suspect alignment problems. Please have a look at the documentation
of FT_Bitmap and read the details of the `pitch' field. For
In summary, please try
./configure --host=x86_64-w64-mingw32 --build=i686-pc-cygwin --with-zlib
--prefix=/cygdrive/c/Library/base CPPFLAGS=-I../../base/include
LDFLAGS=-L../../base/lib
(the difference is --build=xxx)
Toshiya-san,
do you think it makes sense to add a
There's a build error on Mac OS X (10.7) w/ ttfautohint version
0.8: for some reason, the `--libtool` argument to freetype-config
gives a path to a nonexistent library. I do think the right
argument is `--libs`. Please find attached patch.
[...] I can imagine to modify the
As a way of ping, I going to throw in a much simpler
FT_Outline_Get_Orientation patch. So the whole collection of three
patches now looks like the attached. Comments, suggestions?
I've applied all three patches. Sorry for the large delay. Please
test.
Werner
Folks
an hour ago my computer screen backlight has died. :-( It will take a
few days until a replacement screen arrives, delaying most of my
computer activities. Fortunately, I've found a company which still
offers a 1680x1050 display for my old Dell. It's depressing to see
that there are no
an hour ago my computer screen backlight has died. :-( It will take
a few days until a replacement screen arrives, delaying most of my
computer activities.
** Very bad news... Blacklight desktop or laptop?
A laptop backlight.
Well, I've read that that Apple is going to sell iBooks with
With DPI = 326 on IPhone 4S and DPI = 264 on IPad, would you agree
that hinting and subpixel rendering becomes less critical, whereas
the speed of the rasterizer needs to be revisited?
This sounds sensible. Speed is always good, so if you want to work on
that, please do so! Whether this is
e.g. when the gap between dot and stem in 'i' gets blocked, it's
bad font design and can easilly be corrected ;) .
Well, I will try to find a generic solution.
Maybe because the latin module of TTFAH treats i (and j) using
the blue zone of small letter likef (fijbdkhl), when the design
Applied patch and used the -x argument and that resolved the
issue :)
Great!
Does it make sense to add the option (for bold fonts) to vary the
ppem at which the x-height can be increased? Or should the default
simply be 20ppem for all fonts?
I vote for a different solution (and Erik
Is there any test suite, or test code, or anything else that might
be executed after the code is changed and ensure that the code still
works as before?
Unfortunately, no. I normally use ftview on a bunch of normal and
weird fonts for testing, manually inspecting the results.
Werner
From the NEWS file:
* Option `--increase-x-height' now has a mandatory argument (in the
range 6-20 or value 0 to disable it, default value is 14).
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I was playing with Unicode box characters, and noticed that DejaVu
Sans creates the glyph for ▟ out of three quadrant boxes. At
different sizes I can see very noticeable seams where the sub-glyphs
meet. I thought FreeType would handle these cases better, but seems
like I'm wrong. Any
I understand that maybe I am asking too much but even list of font
names will help. Maybe you could share the list?
For testing crashes and the like you might look up the FreeType bug
reports, which usually contain snippets also.
Attached you can find the output from
(for i in *; do
The only potential change in question is this:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=7baeeafcec7fd2267191937e14c1f753424beb89
Your guess was not wrong! This morning I repeated the tests, I had
conducted yesterday. I had been in a hurry and obviously mixed
[...] let's bring FT_GlyphSlot_Embolden in agreement with what
ftview does. This removes too much width that used to be added to
the emboldened glyphs.
Thanks. Do you have time to provide some documentation also?
Werner
___
Freetype-devel
ttfautohint 0.9 has been released.
The source tarball, statically-linked binaries for Win32 (TTY and GUI) and
OS X (TTY only) are available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/ttfautohint/0.9
Enjoy!
Werner
PS:
Great time for asking then: are subglyph positions rounded as part
of the hinting process?
It depends on a flag in the glyph's data, ROUND_XY_TO_GRID, if the
subglyph's offset is given as xy values. However, for the particular
DejaVu glyph, the subglyphs all have a zero offset, but point
BTW, checkout DejaVuSans at 4pt. I see all kinds of triangular
artifacts.
Not my problem :-) According to the font's gasp table, hinting should
be switched off below 9pt.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
BTW, checkout DejaVuSans at 4pt. I see all kinds of triangular
artifacts.
Not my problem :-) According to the font's gasp table, hinting
should be switched off below 9pt.
See attachment.
Yes, I know. I can only repeat: The bytecode goes havoc because it
doesn't work at this size. This
It depends on a flag in the glyph's data, ROUND_XY_TO_GRID, if the
subglyph's offset is given as xy values. However, for the
particular DejaVu glyph, the subglyphs all have a zero offset, but
point coordinates are rounded to integers anyways as part of the
normal rasterization process.
See Spooky G, attached :).
This *is* nice!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
I render the pdf text use freetype, but it is different with adobe
acrobat shows, is there anyone can analyze the reason?
The font in question must be rendered with TrueType hinting, otherwise
it produces the bad results you get. For example, ghostscript 9.05 is
doing this. Simply try to
Filed here:
https://bugs.freedesktop.org/show_bug.cgi?id=50848
Thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
I create face with Calibri.ttf(this file on windows system fonts
dir), [...]
AFAIK, this font needs ClearType handling of the bytecode for good
display. This is not implemented yet (but should be available as soon
as the Infinality patches are integrated).
I would be very interested in the
Attached is my proposal to fix this issue, please try.
Looks good!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
It seems that non-family-names (e.g. full name, PostScript name etc)
are not truncated. Should I add an extra check to compare these
non-familyname strings with the blacklist of tricky fonts?
I vote for `not yet'. It seems that your current approach with
checksums works fine. Let's wait
thanks，another question，is there 64bit freetype2 lib officially
release？I build a 64bit lib locally, but crash at running time in
my application.
AFAIK, FreeType builds just fine as 64bit. Can you debug the problem?
Werner
___
Freetype-devel
If you make the compiler include the header files by compiler flags
written in project file, please post project file too.
Uh, oh, a C or C++ snippet should always be compilable on the *command
line*, even on Windows! This is the only way to get something
portable, more or less.
Werner
embeded font 1_BKLGIB+FA.ttf i sent yesterday to test:
** Not possible to test anything with the font you sent (Fontlab,
** fontforge, TTX). try to see other glyphs !
The font is OK. As I've mentioned before, it is *not* possible to
edit this font with FontLab or FontForge! You need a
... Are you really writing code without indentation?
#include ../../ft2.4.9/include/freetype/internal/ftobjs.h
Uh, oh! You must never, ever use an internal header file in your
source code (except for special reasons).
int load_flags = 8;
Any reason why you don't use the symbolic value,
Do you understand the Rx calculations?
Not without a lot of time to introduce myself to the code :-)
They are wrong if integer overflows, aren't they?
Yes, it seems so, but up to now we haven't had a bug report.
So there will be artifacts, possibly very small ones, when
SMulDiv_NoRound
I attached the TTF in your sample PDF, and attached PNG is my
rasterization result. I think it's OK.
Toshiya-san, thanks for testing! Please commit.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
now, what i need to modify?
or, i render error, you are still right?
You should check your programming environment! Your program
*certainly* links with a wrong, unpatched FreeType library version.
And *please* do your homework right! If we ask for a simple example
which can be compiled on
Let's not rush with this and just say that your fix is incomplete
for now.
OK.
I have a completely new ftgrays implementation without '%' that
works quite nicely.
Aah, great to hear!
Werner
___
Freetype-devel mailing list
it is my programming environment problem! I spend a night do the
check, my homework is bad. it is render right now! Thanks again for
your patience and i Will be more rigorous.
You are welcome. Great that it works now.
Werner
___
What are your thoughts on implementing horizontal stem snapping in
the autohinter?
It's certainly worth an option. BTW, if you say `make devel', the
option AF_CONFIG_OPTION_USE_WARPER is in use which goes into a similar
direction but trying to minimize the glyph shape distortion. Have you
Folks,
I'm going to prepare FreeType release 2.4.10 within 24 hours. In case
you want to contribute something urgent, please do it right now.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
FreeType 2.4.10 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file;
I think, that could work like this: the software has to build and
you conture around any glyphe, in a way that the distance to the
outline of the glyphe is depending on its form, so that the new
outline is closer to sharp edges then to straight lines. this could
be done in the way I have
The only reason I bring up the horizontal stem snapping (outside the
context of a new autohint API) is that it could be implemented
without needing to add any new variables, and without using the
warper.
I don't object to any improvements, but I would like to be able to
compare the
For those interested, the latest release is available here:
http://www.infinality.net/blog/infinality-freetype-patches/
Very nice!
Some remarks regarding
freetype-add-subpixel-hinting-infinality-20120615-01.patch:
. In line 1440 I see this:
+#endif /*
Next patch will have all the issues you brought up resolved.
Great! Thanks a lot. There is a last problem, namely a proper
ChangeLog entry. However, if you have a final code, I can prepare
this for you before you are getting desperate :-)
Now, if I can just figure out what the deal is with
If I am unable to connect in the next hour or two, I can send you
the patch.
The patch is now in the repository. Thanks a lot!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hope to see rest of the infinality patchset in later on :)
This will take a longer time, since we first have to implement a
proper infrastructure to control the auto-hinter.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I really dislike how you disabled hinting in the x-direction. [...]
Thanks for your reviews, and please continue. I'm sure Erik will
collect them all :-)
Note that I won't do any changes right now; instead, I hope that
Erik's SSH problems are gone soon so that he can maintain the code by
Folks,
I've just added GDI ClearType support to ttfautohint. This gets
automatically detected, so no user action is required.
Please test!
Note that you won't see a difference with FreeType (except if you
patch the sources); you should rather use an older Windows version
like Win XP which
Did you also tweak something else in ttfautohint very recently? I'm
on latest 0.9.6-6446. Latest TTfautohinted fonts under DirectWrite
render noticeably better than those from previous weeks builds.
Stems look much crisper across the x-axis :) Whatever you did, was
good.
Interesting, since
Well looking at the git repo i notice the latest build added
function for different flavours of cleartype rendering;
Yes, but you've written that you are using 0.9.6-6446! The latest was
0.9.8-470f until one minute and is now 0.9.9-c45e.
I assumed this what partly was effecting rendering
I'm trying to compile the last version of TTFautohint from GIT, maybe
I mess something...
After git clone git://repo.or.cz/ttfautohint.git
then ./bootstrap
then ./configure
'Make' returns an error : no makefile found
If you look at the configure script you can see that it exits with an
The attached patch changes the way 'ftview' fills the window with
glyphs so that the right margin is less blank and a larger number of
glyphs shown. It uses the actual width of the current grBitmap,
instead of super conservative max_advance, when fitting the glyphs
in the available space.
I was wondering if anyone on this list might be able to help me work
out the effort required to support the FF Chartwell font in freetype2:
https://www.fontfont.com/how-to-use-ff-chartwell
Direct support in FreeType? Nope. You need either Pango, ICU, or
HarfBuzz which are OpenType
I've picked FT_Err_Raster_Overflow to indicate the boundary. Is
that appropriate?
No, it isn't IMHO: FT_Err_Raster_Overflow is a fatal error, indicating
a serious problem which the rasterizer can't manage. I think a simple
integer will serve as return error instead of FT_Error.
I am also
Is there anyone interested in adding WOFF support directly to
FreeType?
Yes, I will eventually add it but have'nt found time yet.
It's a trivial amount of work. Basically you copy the SFNT code,
slightly modify it, and hook up the gzip decompressor to the
tables...
Patches, please :-)
[...] the drawing functions ultimately inherit the error codes from
FT_Glyph_To_Bitmap currently. Therefore it has to be something
different from those defined in fterrdef.h to distinguish. It would
be good if freetype reserved an FT_Err_User, defined as -1 or 0xFF
perhaps, which is not
-AC_MSG_RESULT([whether CFLAGS and LDFLAGS share ${c}])
+AC_MSG_CHECKING([whether CFLAGS and LDFLAGS share ${c}])
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Update LDFLAGS only after LT_INIT has run.
Applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
From the documentation:
### Stem Width and Stem Positioning
`--strong-stem-width=`*string*, `-w`\ *string*
: ttfautohint offers two different routines to handle stem widths
and stem positions: 'smooth' and 'strong'. The former uses
discrete values which slightly increase the stem
In theory, what difference should there be under which render
settings?
First of all, I'm not sure whether the selection of the three
rendering modes really works as expected. My only test was with
current git version of FreeType, and there everything's fine...
To be sure to really see the
I will try and do some extensive tests tomorrow; sans, serifs, win7,
winXP, diff browsers, etc. I will prob add in Android too, as
ttfautohint can effect fonts under Freetype too.
Thanks in advance for that! I think it's best to directly compare the
algorithms (this is `-w gGD' vs. `-w ')
On closer inspection it is the 'G' option that gave the only
'different' rendering i saw, and it's not overall better anyway.
If you say `-w G', this means that you get the smooth algorithm for
gray and DW ClearType, and strong for GDI ClearType, at least in
theory.
Shots attached.
Thanks!
I've got a bit lost keeping up with what rendering the different
browsers on Windows* use now.
Here is a nice table:
http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/
No idea whether this is correct, though...
Werner
PS: I faintly remember that there
Here is a nice table:
http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/
No idea whether this is correct, though...
Reading the comments on that page, it seems that it is *really*
complicated. Another facet is that according to
Those shots were using the win7 system font viewer- which I think
makes it plain old gdi cleartype?? Don't think direct write at
system level comes until win8. I maybe wrong, but I thought dw was
found in explorer 9 and Firefox 7+ but not the win system.
Aah. Then the rasterizer logic in
It is OpenSans Regular from the Google webfonts server.
Thanks.
you mean https://browserlab.adobe.com/en-us/ ?
Yessir!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
PS: Who knows a TrueType debugger for MS Windows (this is, which
uses the rendering engine of MS Windows!) similar to FontForge?
Ideally, this should run under Wine also...
But on Wine, it'll use FreeType rather than the MS rasterizer, so
what exactly is the point? :)
The point is
Hello Vern!
In git, I've now fixed the situation displayed in your
`Capture-G-win7GDI.png' image (showing Open Sans at 21px, please look
at the ugly rendering of digit 3, for example): It was a buglet in
FreeType's autofit module which didn't show up because of its smooth
rendering algorithm.
widths which are different less than or equal to 1% of the em size
are unified; this is certainly not noticeable visually.
1/64 is better heuristic than 1%. Why not avoid costly division with
divide by 64 instead.
I doubt that it is `costly' since the routine is called exactly twice
*per
1101 - 1200 of 3661 matches
Mail list logo
