During the business trip, I was trying to reproduce the trouble that
Dave Viner got in
http://lists.gnu.org/archive/html/freetype/2006-05/msg00035.html ,
and I found I made an overestimation about bad impact of the chained
dependency. Please let me explain. [...]
Thanks for the analysis!
My question is: where should I look and/or what should I change, to
make them act the same?
The FT_INT64 stuff is only used in a single file, `src/base/ftcalc.c'.
However, AFAIK, the GNU C compiler always defines a 64bit data type
(`long long int'), so I'm really surprised that you experience
I've verified that replacing #undef FT_CONFIG_OPTION_FORCE_INT64
with #define in include/freetype/config/ftoption.h does prevent the
#undef FT_LONG64.
But that shouldn't be needed on LP64 archs.
Perhaps the #if FT_SIZEOF_LONG == 8 case should also #define
FT_CONFIG_OPTION_FORCE_INT64 ?
In particular, it appears to me that the ARM system is doing some
incorrect math from the metrics width value of 0x2C0 to get 0x800,
but I'm having trouble identifying why this might be.
Finally, can you decorate the various functions of ftcalc.c with
some printf calls to find out where the
ftgrid has been improved.
. Added key `f' to ftgrid to toggle forced autohinting. This might be
interesting for some of you since you can toggle vertical and
horizontal hinting independently.
. Autofit debugging messages can now be controlled via
FT_DEBUG_AUTOFIT in ftconfig.h (AF_DEBUG
Attached is how the font NanumGothic.ttf (downloadable from here :
http://hangeul.naver.com/download.nhn scroll down to the 7 green
boxes and it's the third one along the top row) looks:
@ Pixel Size 13
[cid:C2DDDF1F-E850-4D87-B865-45318241A5C1]
Notice how the letter i appears to be too
A few months ago you've written:
Are there any tool which visually present segments of autofit
module? Something like stems shown in the glyph view of fontforge.
No, but I'll probably add this to ftgrid since it would be helpful for
my work on the ttfautohint stuff. But it isn't an urgent
Also I attached the comparison of 3 typefaces.
Just a general question: Are you using B/W rendering in your images
for demonstration purposes only? At such small sizes, the autohinter
produces bad results if not using AA rendering. Even with TT
instructions, CJK fonts normally contain bitmap
Every user of FreeType that I know has once in their lifetime hit
the bug that with many common CJK fonts, non-CJK characters take
doublewidth where they should take a single one. The fix always has
been to pass FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH to FreeType, as the
fonts have the bit set
One of my anxiety was that the priority to the black/white evenness
can reduce the contrast of the complex glyph. Please find attached
picture comparing the results by HeiseiMaruGo-W4 at 16pt @ 72dpi. In
my personal impression, the legibility of the strokes in enclosed
area (like 日 or 目) is
Since your suggestion sounds sensible, could you provide a patch?
Attached.
Applied, thanks.
You also need to update the ft2demos that use it to remove the
option (ftdiff, etc).
Done too.
Werner
___
Freetype-devel mailing list
I propose following update as the minimum back-compatible patch
for next release of FreeType2.
Please decide yourself which of the two patches should go into the
repository.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
There are indeed some problems with the patch. They happened when
the bluezones were scaled at af_cjk_metrics_scale_dim() [...]
I update the patch to the current git and address the problems.
Please review the logic behind the idea.
Thanks! I leave this to Toshiya-san for testing.
There
Are there any tool which visually present segments of autofit
module? Something like stems shown in the glyph view of fontforge.
No, but I'll probably add this to ftgrid since it would be helpful
for my work on the ttfautohint stuff. But it isn't an urgent
issue, and in case you have time
Considering that the number of blacklist is increased to 13, I
changed the algorithm to compare the checksums slightly.
It seems that the fonts are not so popular, so this is not urgent
issue. Please give me comment.
Your patch looks fine. I haven't tested actually whether it works,
but i
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 :-(
Uh, oh. Please write a bug report to the OpenOffice/LibreOffice
people. It seems to me that we can't do
For some reason I assumed that FreeType would be calculating the
checksum. I'm sure there's lots of code that doesn't bother to set
the checksums at all.
The problem are subsetted fonts, I believe.
Werner
___
Freetype-devel mailing list
I've had some hope to show working bytecode stuff at the beginning of
May, but things are a bit more complicated, unfortunately: While the
library has been extended to support generated bytecode already, I
have first to define some auxiliary bytecode functions to support
hinting similar to
Here is 2nd testcases checking ca. 1900 fonts [...]
Thanks. Since this is a once-per-font operation, I don't think we
should think too much about timing issues. Please proceed.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Just I've committed to make tricky font detector to ignore the
existing checksum written in the TrueType header, [...]
Thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
At present, configure script always uses mmap() if it is found, so I
added an option --disable-mmap to ignore it. Although this is
only for developers who want to make irregular configuration, is it
meaningful to merger in official source code?
If you think this is useful, please add it!
Okey, I add the accessor functions to afhint.c.
I also made the segment drawing independent of the force autofit
mode. I found that the segment lines are useful reference with or
without autofit turned on.
Applied with modifications, thanks.
One observation I had is that in order to
For CJK glyph, There are alway many diagonal stems that needed to be
fit with blue zones. However, since we cannot produce a horizontal
or vertical segment out of a diagonal stem, the stem cannot be blue
zoned, e.g. the top and the bottom of 户.
To solute the problem, I suggest to treat
If these difference is not so important, I propose to change
sfnt_get_ps_name() to thin wrapper of tt_face_get_name().
Looks good. If you don't notice adverse effects please commit.
Werner
___
Freetype-devel mailing list
I find the random generator, but it can’t explain what I’m
experiencing.
Have you read this comment in the description of FT_Library
For multi-threading applications each thread should have its own
FT_Library object.
and are you following the advice?
Werner
Question for the FT developers : why was this seed calculation
implemented this way ? And not e.g. a fixed start value associated
with each FT_Face created ? That would make FT output reproducable
(and testable for detecting regressions).
I have no idea. :-) Patches are welcome. Up to now
It turned out that the culprit was, that the surrounding anchor points
have no 'out direction' when searching for segments. [...]
Cross out that part will solve the problem for 一 , of cause might
also screw up some other parts. It's there to keep the tangent small.
Any suggestion on how
Thanks for you suggestions! Working with bytecode instructions must
be actively trained, like any other programming language, then the
obstacles diminish.
Maybe you can make use of the xgridfit tool to semi auto-gen the TT
instructions.
Maybe. However, the idea was to write a library in C,
How long do you need to find stable values for the tunable
parameters?
This is never finished :-) Even for the latin autohinter, improvements
or different approaches are always possible (cf. `latin2').
If it is difficult to estimate, I will propose new API
to manipulate the parameters by
In af_cjk_metrics_scale_dim(), when we scale the blue zone to the
font size, the blue zone is also rounded to pixel grid. The offset
introduced in the rounding at both the bottom and top could have
undesirable effect on the glyph height at certain font size. [...]
Again, it would be great if
builds/unix/install-sh is a file installed by automake, so it is
modified when autogen.sh is executed. I think it is something like
config.guess and ltmain.sh, so I registered install-sh to
builds/unix/.gitignore and builds/unix/install-sh is removed from
GIT repository.
Thanks!
I'm adding vertical text support to HarfBuzz and it occurred to me
that FreeType's vertBearingY and vertAdvance metrics have a Y
coordinate growing downwards, while all other Y coordinates in
FreeType grow upwards. Thought that may be worth documenting.
Could you provide a patch, please?
How about this:
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
The last days there was a lot of progress in ttfautohint. I thought
that the whole framework was finished, and I only had to fill up
missing bytecode. However, while doing so, I found out that I've made
a fundamental design error.
The idea was (and still is) to compute and collect `hinting
Toshiya-san,
sorry for the late reply.
If you can remember why current FT_IS_CID_KEYED() ignores t1cid,
please let me know.
It simply looks like an oversight. I can't see any reason why t1cid
fonts should be excluded.
Werner
___
[I'm CCing the FreeType and lilypond devel lists since this is a
problem which has not been reported to FreeType, and which has caused
problems with PS files created by lilypond.]
Peter,
the font `verdana.ttf' version 5.03 (shipped with Windows 7, I
believe) contains the following two
The last two days I've rewritten a large part of the bytecode in
ttfautohint to use twilight points for representing segments.
FreeType's autohinter treats segments as if they were a single point,
located in the middle of the maximum and minimum coordinate value.
The previous code in ttfautohint
[Vern, I take the liberty to answer on the list also.]
That's very interesting and gives some pretty good results. If
no-one else has done so i am happy to run some specimen tests
produce screenshots.
This would be great! Please wait a few days until I've fixed the
problem with composite
I think i remember you saying that ttfautohint will not have a GUI.
Is that still the case?
Yes. ttfautohint is a library (with a single API function :-), and
the `hint' program is just a small demo using it. Writing a GUI
front-end might be a nice job later on, but it has no priority for me
One major problem still remains which I have to resolve in the next
days: Composite glyphs are rendered incorrectly.
I've fixed that now. However, letting the autohinter handle subglyphs
separately will always produce inferior results if compared to
handling all subglyphs together at the same
but i am embarrassed to admit that i have built the library but have
not found how to use the 'autohint' function :) a quick howto,
please!
One important thing I've forgotten to mention: You need the current
git version of FreeType to test the ttfautohint library; the
`configure' test for
Vern,
I have now added some simple upper lowercase waterfall tests to
'ttfautohint tests' at http://code.newtypography.co.uk
thanks a lot for the tests and the test images! Please post a URL
where I can download the Ubuntu font you've used.
Of note is that at larger sizes (20px - 30px)
Finally, there is the problem of glyphs which can't be addressed
with a cmap directly, like small caps which are activated by an
OpenType feature. Similar to FreeType's autohinter, such glyphs
don't get any special consideration and are treated by the default
hinting module (in FreeType this
The 'stretched' x-height could be a matter of taste, but personally
i would like to see the autohinter err on the side of less
stretching if possible.
Hmm. I could add the ability to switch off x-size snapping, and I
could also change the rounding rules to something similar the SROUND
Mhmm. Up to now I've *never* seen a font rendered with FreeType
which shows such a large deviation from the Windows font engine. I
believe that FreeType's output is quite trustworthy.
heh. Really? Depends what you mean by 'large deviation' i guess. I
only ever seem to see differences
... And indeed, comment #39 says:
The following upstream commit fixes this problem in freetype 2.4.x:
commit 75787c19eab20874c5d588842c52e59cfbd9302a
Author: Werner Lemberg w...@gnu.org
Date: Sat Jun 26 09:24:08 2010 +0200
Add some memory checks (mainly for debugging).
* src/base
Just posted screenshots of ttfautohint output under DirectWrite
(Cleartype Grayscaling).
Thanks again for your invaluable help in testing ttfautohint!
Interesting. imo, generally the ttfautohint output is superior to
the original fonts' output, though there are some glitches, e.g. dot
FreeType 2.4.5 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/project/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file;
I am curious - as i understand it(?) ttfautohint uses freetype to
find snap zones etc from which it bases it's TT instructions output.
I've copied a large part of the autofit module into ttfautohint;
additionally, I'm calling some FreeType routines for generic reading
and parsing of the input
in openSUSE we apply a patch called freetype2-bitmap-foundry.patch
which seems to add foundry support to PCF font files, likely to fix
the problem reported over at
http://lists.freedesktop.org/archives/fontconfig/2006-February/002072.html
. The patch is attached for your inspection, can
ttfautohint 0.1 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/project/freetype/files/ttfautohint
Enjoy!
Werner
--
This project provides a
ttfautohint 0.1 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/project/freetype/files/ttfautohint
Oops! This should be
http://sourceforge.net/projects/freetype/files/ttfautohint
Werner
The 'final image' is simply the ttfautohint instructions with the
addition of links (double links work best in this instance). I did
no extra hinting from fontlab - [...]
[...] if i look at the same font in FontForge's Gridfitmode, then i
don't see the egging issue at all.
Exactly! Such a
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.
Mhmm, not really IMHO. For me,
Since freetype no longer uses CVS attached patch could do the job.
Applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Please find attached a major revision of ftstroke.c/h.
Thanks a lot! I've committed it to the git repository, doing some
slight formatting.
Ideally, it would have been better to isolate the various unrelated
fixes into separate commits, but I know that this can be a very
time-consuming
I think only the documentation for FT_Stroker_LineJoin will need
updating to match the new ftstroker.h.
Perhaps this happens automatically.
It does, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
What i have noticed with ttfautohint is that often e.g. a regular
weight of a font will grow in size at a bigger % than the bold
weight. So i'm thinking the Regular is 'over-hinted', maybe.
Well, ttfautohint has no possibility to decide whether a font is bold
or not... The Infinality
Folks,
I'm going to apply the change below (in sfnt/sfobjs.c). Only if a
font has zero values for `hhea' table's ascender and descender,
FreeType tries harder to find reasonable values.
Any objections?
Werner
==
old
Attached is a patch for tafpgm.c; please apply temporarily to make
the `fpgm' table four bytes longer.
Thanks for that.
Have you been able to test that? Are fonts generated with the
slightly larger `fpgm' table rendered correctly, or do you still get
an egg-shaped `O' glyph?
Otherwise, I'm
My patch file looks like this (taken from your post) -
diff --git a/src/tafpgm.c b/src/tafpgm.c
index 1268e29..3874844 100644
--- a/src/tafpgm.c
+++ b/src/tafpgm.c
@@ -4298,6 +4298,11 @@ unsigned char FPGM(bci_hint_glyph) [] = {
ENDF,
+ PUSHB_1,
+100,
+ FDEF,
+ ENDF,
Folks,
has anyone more information on the recent exploit for the iPhone,
reportedly caused by a problem within FreeType's
`t1_decoder_parse_charstrings'? Extracting the buggy font from
http://www.jailbreakme.com/saffron/_/iPod_4.3.3_8J2.pdf
and testing the current ftview (from the git
==
diff --git a/ChangeLog b/ChangeLog
index 25fb10c..c58d6bf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-07-08 Werner Lemberg w...@gnu.org
+
+ [psaux] Add better argument check for `callothersubr'.
+
+ * src/psaux/t1decode.c
I would have this check under default: on line 1013 because other
cases have good checks already.
But the `default' label continues, while `Unexpected_OtherSubr'
aborts...
That default is rather strange: wish me luck. Really?
:-) Obviously, you aren't aware of TeX's warning messages like
Moving error check down to default, where it belongs
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
I've been working on a bug for webkit related to an odd behavior
with the Ahem font in the Qt framework. I tracked it down to Qt
either receiving incorrect descent/ascent values from
FT_Size_Metrics or using the Freetype library incorrectly.
Within TrueType fonts, there are three sets of
I've been working on a bug for webkit related to an odd behavior
with the Ahem font in the Qt framework. I tracked it down to Qt
either receiving incorrect descent/ascent values from
FT_Size_Metrics or using the Freetype library incorrectly.
When using FT_Set_Char_Size(face, width,
What do you know about this one: CVE-2011-1908?
Nothing.
Is this the same issue or an older one?
I don't know. Nobody has contacted me recently. Some months ago,
people from Foxit have sent a bunch of problems which I've tried to
fix in the git repository (thus all related patches are in
:
commit 6b3d00e1a0bc5033aeeab51912eda0aff6ed6e8b
Author: Werner Lemberg w...@gnu.org
Date: Tue Feb 3 21:34:29 2004 +
* src/type1/t1load.c (parse_dict): Handle `RD' and `-|' commands
outside of /Subrs or /CharStrings. This can happen if there is
additional code manipulating
I've made a patch for the proposed change below. Please let me know
if anything needs to be adjusted.
The patch looks good, thanks. Just for the record, please give some
numeric values for your problem with the Ahem font so that I can
identify and handle potential issues in the future more
Here's the answer from Matthias.
1) Fix2Int does shift before conversion. How does it solve the
undefined behavior with negative numbers?
After the shift, the upper half is undefined. The cast to Short cuts
off the upper half, and the following cast to Int does the sign
extension in a
For reference if anyone is curious, any pixel size that is not a
multiple of 5 will exhibit the problem. A couple common ones are
72px and 96px which should be a 72x72 and 96x96 respectively.
Leading is 0 for Ahem so height should be ascent+descent.
$BUU$(Q.-(B
I've applied your patch.
I'd like to build a static library version of Freetype2 that does
not link in libgz or libbz2. May I assume that disabling support
for gzip and bzip2 compressed fonts would do that? How would I
disable this?
If you say
./configure --help
you can see this, among other information:
ttfautohint 0.2 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/project/freetype/files/ttfautohint
Enjoy!
Werner
--
This project provides a
ttfautohint 0.2 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
both these links seem to be 404 errors,
:-/
Don't miss the small print on that page :-)
Downloads will redirect to your nearest mirror site. Files on
mirrors may be subject to
Here is an updated version and a changelog entry. I'm not sure if
I'm 100% happy with the wording of the option comment though.
Please let me know if there are other changes that I should make
here.
Thanks. I've modified your patch to bring it in line with the
conventions of FreeType.
This is NOT a recent regression and should not hold 2.4.6.
But why is the attached so ugly?
A very good question! Fortunately, you shouldn't see this in real
life if applications properly follow the data in the `gasp' table.
ftview 4 /usr/share/fonts/dejavu/DejaVuSans.ttf
and toggle 'h' a
I sent privately to Werner yesterday, but since the sites are
public, I guess it might as well go to the full list. [...]
And I replied that I'll do a new release today :-)
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Werner, you are right, it should be reflected in the CHANGES. The
changes result in better, more consistent line spacing. DejaVu got
one point smaller, there is nothing wrong with that too.
Done. Thanks for the images!
Werner
___
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 holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file;
Here's a link to a really fascinating article on creating a smallest
TrueType font. I've enjoyed it a lot!
http://processingjs.nihongoresources.com/the_smallest_font/
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Here's a small set of patches I'd like to get in to the official
tree. [...]
Thanks!
Let me know if you have any questions or need more info.
Please send me the broken fonts privately which trigger the problems.
I collect such beasts :-)
Werner
This might be interesting to you:
http://www.freetype.org/ttfautohint
Enjoy!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
We are considering using your program “freetype 2.3.5” in our
products.
This is a quite old version. I recommend the current one, 2.4.6.
Before going any further, however, we would like to confirm
the following so that we are sure to fully respect your rights.
You are the author and owner
Louis,
your attachment is too big for the mailing list. Additionally, it
contains a non-free font which is not allowed to be distributed.
Please resend it without the font, if necessary, and I'll forward your
mail to the list.
BTW, trying to compile with
g++ -o Standalone \
-O0 -g \
The main difference between the standalone and Android app is the
way that the input TTF file is read in, however I verified that my
TTF file is read in correctly in Android, by writing out the buffer
that I read in to a new file, and then comparing the original with
this - they are
ttfautohint 0.3 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/ttfautohint
Enjoy!
Werner
PS: Downloads from savannah.nongnu.org will redirect to your nearest
mirror site. Files on
This means that FreeType is fine and DejaVuSans's hinting at 4ppm is
buggy. :-) Due to the `gasp' table, this is a non-issue anyway.
It cannot be both non-issue and buggy font.
The hinting at 4ppem *is* buggy. However, the gasp table prevents
hinting at this size, for exactly that reason.
What is the expected behavior of FT_Load_Char when the requested
glyph is not present in the font file? One user of freetype-py
(http://code.google.com/p/freetype-py/) reported that freetype
returns no error (and does not load the glyph obviously).
FT_Load_Char is always successful
cannot find -lz
This dependency is from FreeType itself. Say
./configure --without-zlib
to use FreeType's LZW implementation.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
This is a final version of the patch that optimizes both conic and
cubic flatteners. Polished and tested. Please consider.
Sorry for the long delay. It looks good
I've applied it to the git repository, thanks.
Werner
___
Freetype-devel
I check if my TTF file has kerning information using FT_HAS_KERNING,
and this returns true. I then use: FT_Get_Kerning(face, prev, next,
FT_KERNING_DEFAULT, delta); to determine the kerning value, but
delta.x returns 0. How can I debug why the kerning value is 0 even
though FT_HAS_KERNING
Also - as I have already invested much time in Freetype I no longer
have time to integrate a different library such as Pango - is there
somewhere I can obtain freely distributable TTF files that contains
kerning information that can be handled by Freetype?
If a font doesn't contain a `GPOS'
My original problem persists though and there is too much spacing
between certain characters, such as F and a, and between 1 and
almost any other number. Is this not something that should be dealt
with by the kerning table, or do I now need to look for a different
font?
I think that your
If any one could answer my (silly?) question. I need to use
FT_Set_Char_Size() to set my character size at point 7,25 (verdana).
Since this function accepts FT_F26dot6 as the char height and width, I
am wondering how I can set point 7,25 without losing data
if I cast 7,25 to FT_F26dot6.
As
Using the following code with the attached (very small) font:
No font attached. BTW, never ever send complete non-free fonts to
this list! Small, subsetted ones are OK.
I'm getting the following output:
Num glyphs: 3
char: 32 (index = 1)
char: 160 (index = 1)
How do I get the last
I'm getting the following output:
Num glyphs: 3
char: 32 (index = 1)
char: 160 (index = 1)
How do I get the last char ? (or did I do something wrong ?)
Without seeing the font this can't be answered. For example,
character code 160 might map to the `space' glyph, having glyph
index 1
Sorry for the late response.
I'm trying to figure out if the following two snippets of code will
load the glyph in the same way in all cases...
Snippet#1:
---
FT_Set_Transform(face, NULL, NULL);
FT_Load_Glyph(face, glyph_index, load_flags);
Snippet#2:
---
The decision is based on the transformation matrix without
considering if the FT_LOAD_IGNORE_TRANSFORM bit is set. Is this a
bug? Does the glyph always get loaded the same way in both cases?
This really looks like a bug. Can you provide a fix?
Here is a patch. :)
Applied, thanks!
[...] maybe someone meant the following?
/* apply `standard' transformation if no renderer is available */
if ( internal-transform_flags 1 )
FT_Outline_Transform( slot-outline,
internal-transform_matrix );
if ( internal-transform_flags 2 )
901 - 1000 of 3661 matches
Mail list logo
