The attached patch returns the error code 0xFF when the margin is
crossed and leaves 3 pixels blank at the right margin.
I've just tested it, and it fails for fonts which can't be emboldened
(for example, BDF). Besides that, it looks OK.
Werner
inline:
Personally, I think that the value 1% is easier to comprehend than
the value 1.5625% (to which a division by 64 is equivalent), so in
this case I prefer the human to the computer.
Tell this to any American who would prefer 1/32th of an inch to a
millimetre before you finish your sentence.
For the record, I prefer 1/64. :) (Coincidentally I am also
American)
My favourites are screws with a head size of 39/64 or 7/16 inch, say.
http://www.wlfuller.com/html/wood_screw_chart.html
This sounds *so* natural :-)
Werner
___
Freetype should go to the metric system... we could replace all
26.6 variables with floats! What do you say??
Basically, I don't object; the IEEE floating point architecture is
well standardized today. However, it's a major undertaking, and I'm
not sure whether it is worth the effort. In
Folks,
please test the current git. I have slightly changed the code in the
auto-hinter which recognizes flat segments; it now accepts a broader
group of shapes. As a consequence, handling of serif fonts like
Palatino or Quattrocento should be much improved.
I have also imported this code to
I hit a bug in an iOS + ARM build of FreeType where the ADDS
instruction in the FT_MulFix_arm assembly fragment was clobbering
condition codes. The following patch adds cc to its clobber list.
Applied to git, thanks.
Werner
___
Freetype-devel
Call ft_new_glyph with a real glyph, not casting bitmap and set
bitmap only after that call.
Applied, with slight modifications.
Thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
ttfautohint 0.91 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.91
Enjoy!
Werner
PS:
On some composite glyphs where a diacritic accent joins the main
contours of a glyph on the baseline (e.g. ccedilla scedilla) the
stem on the baseline fails to snap properly and instead renders very
bold. If i turn these same glyphs to outlines and remove any overlap
then rendering and
Toshiya-san and I have met in Osaka, and we have enjoyed a great time
visiting the private museums of Motoya and Morizawa, two big font
companies in Japan.
While having a nice lunch, we've discussed how to control modules in
FreeType. In FreeType's `autohinter-properties' branch, I've posted a
At the moment ttfautohint can increase the x-height by using the -x
argument, but switching this feature off (-x 0) still increases
x-height compared to the original instructions. Would it be possible
for ttfautohint to decrease the x-height snapping by 1px at
particular size range? :)
Brad has shown me a font where ttfautohint's code causes vertical
clipping of glyph `g' on some (older) Windows IE versions since its
depth at same ppem sizes exceeds the usWinDescent value.
Uh, oh. This was caused by a very embarassing bug: one of the central
bytecode routines to round to
I still think the issue here is the way the Freetype auto hinter
snaps to pixel edges.
This is *another* issue.
It tends to snap 'upwards' compared to the bytecode interpreter,
which when following manually hinted TT instructions may be
instructed to snap 'downwards' with certain stems at
ttfautohint 0.92 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.92
Enjoy!
Werner
PS:
Would there be any significant differences between the hinting from
a ttfautohint built using Freetype 2.4.7 against one built using say
2.4.10 ?
No, IIRC. The main reason to use newer releases of FreeType is to
avoid potential security issues, but this shouldn't be a problem for
`private'
This looks very much like a winding-rule issue.
Yes.
Despite Adobe's font documentation claiming that glyphs should be
rendered with non-zero winding, the Adobe *font* scalers/renderers
actually use even-odd.
Interesting.
If this looks like becoming more important, and no one else is up
I have added support to cache stroked glyphs.
Thanks! It will take some time until Toshiya or I will be able to
check it and comment.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hello Toshiya-san!
Sorry for the late response.
At present, FTC_Manager instance is allocated with FT_Library's
allocator, FT_Library object itself does not have a (list of)
FTC_Manager, so, it could be slightly difficult for set- property
functions to invoke the cache flusher. There might
Graham, David,
some time ago we had a discussion about the usefulness of a patch from
Alexei:
http://lists.nongnu.org/archive/html/freetype-devel/2010-11/msg00010.html
However, right now the usefulness is evident, since applying the patch
fixes the quite serious issue #37017. :-)
I have added support to cache stroked glyphs. This introduces
caching for stroked glyphs for both a sbitmap, and a regular image
glyph. Also, support has been added to the FTC_Manager to cache
FT_Stroker objects.
I've just had a closer look, and it looks very good!
Modified API:
*
I think the use of the properties for the caching amounts is a good
solution. The only thing I would point out is if the stroker cache
uses this new properties API for configuration, we should also make
sure the cache maximums for faces and sizes can also be configured
with this API. I
The idea is to add just two modes (for the moment - no need to be
over-elaborate) to FT_Pixel_Mode, for premultiplied ARGB, and the
same format using 8-bit indexes into a palette. These modes are
convenient when creating bitmap fonts from PNG images. [...]
This sounds great! Are you going
I'd like to introduce adjustable stroking radius to ftview
functionalities. This is a patch. Please comment.
Thanks; this looks simple and straightforward. Please install.
BTW, what about using integer numbers for slant and radius in the UI
(for example, the real values multiplied by
Folks,
it's embarassing, but I've screwed up my property proposal. The
reason is quite simple: While designing and discussing the interface,
I haven't looked closely enough at the source code, and only now I
have discovered the discrepancy between my faulty memory and the
reality...
However,
What are the void* pointers typically expected to point to...?
Property data structures.
As I suppose these void* values are often pointers to some malloced
memory in many cases, how is it expected that resource management of
that memory is done...? I.e., when the a list gets destroyed
FreeType. If there is ever a need to pass a new string to the
library (for which I currently don't have a use case), the data
will be copied.
Wait how does that work?
That suggests that freetype will copy any structure passed in into
malloced memory or something; otherwise, one
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,
well... This is definitely not my fault :-)
and the proposed property service is a big step in that
direction.
As
That we are considering something as bulky as a generic property
get/set system means either that the original design was flawed, or
we are going into orbit as architecture astronauts.
I'm open to suggestions how to do the following:
. autohinter:
. switch on/off horizontal hinting
Thank you for your prompt response. I am surprised, because when
embedded in a PDF file, the font is displayed incorrectly by
GhostScript 9.02 which uses FreeType 2.4.3.
Indeed, using ftview from 2.4.2 and 2.4.4, the font fails splendidly.
However, version 2.4.6 and later works just fine. I
by */
+/* Copyright 2002, 2004, 2006, 2007, 2010-2012 by */
/* David Turner, Robert Wilhelm, and Werner Lemberg. */
/* */
/* This file is part of the FreeType project
Is this because we ran out of FT_LOAD_XXX space?
This is one of the reasons, yes. Another one is that controlling
modules with FT_LOAD_XXX simply doesn't feel right, since modules
belong to FT_Library objects and not to FT_Face.
Any plans for Freetype3? It's been 12 years. Is it time yet
I think FreeType3 should have some distinction of APIs between the
APIs bound to real single font file, and APIs not bound to. Maybe I
should investigate the existing software and make a list of referred
APIs and their popularity.
Please do so!
Werner
Another example that I recently stumbled across (and haven't yet
investigated fully) is the rendering of notdef glyphs. For Truetype,
Freetype is (correctly) using the TTF notdef glyph (the empty
rectangle), but for Postscript/PDF/PCL/PXL, the notdef is a
non-marking glyph. So, in the event
I just think that Freetype should remain an engine which takes a
font from some source, and uses it to to create outline or bitmap
glyphs. I would not like to see Freetype getting sucked into
loading fonts by name (even if that was done by punting off the
fontconfig), or gaining any kind of
This sounds like a good candidate for a property of the truetype
module...
I think I have a workaround for now, but it would certainly be
easier if it were supported in the library.
OK. I'm still exploring how to introduce global properties in modules
(and, most of all, where to add
I would like to run configure to change the default directories (do
not use /usr/local) but when I run ./configure - even with no
arguments I get the following message
root@x104:[/data/prj/freetype/freetype-2.4.10]./configure
make: *** No rule to make target `setup'. Stop.
Are you using
which reminds me: time to get started on finishing my packaging of php
On Mon, Sep 17, 2012 at 9:06 PM, Werner LEMBERG w...@gnu.org wrote:
I would like to run configure to change the default directories (do
not use /usr/local) but when I run ./configure - even with no
arguments I get
Folks,
I've just committed a first experimental auto-hinter addition from the
Infinality patch: What you could originally control by the environment
variable `INFINALITY_FT_AUTOHINT_INCREASE_GLYPH_HEIGHTS' can now be
handled with the new property `increase-x-height' (and even
fine-tuned, not
Will this arrive in ttfautohint? :)
This is already in ttfautohint since a few months (option -x). For
testing properties, I've first played with this in ttfautohint, and
using the new FreeType property framework, I've added this feature to
the auto-hinter too.
Right now I'm synchronizing
I know i've asked this before :)
Have you? I can't remember.
but, could this concept also be used to Decrease the xheight at
particular char sizes? Because decreasing the xheight can also
increase legibility at some small sizes on some fonts.
I'll add this to the TODO list. Could you
rm -f is used anywhere in configure : no detection is needed for rm
Applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Multimedia container files like AVI or MOV have audio and video
streams, plus optional streams like subtitles etc. Each such stream
can typically use various codecs for various flavors of audio or
video. [...]
Adam, this is an excellent analogy! Thanks for that.
HOWEVER: I must agree
Might the suggestion that FreeType could perhaps /parse and expose/
all tables without necessarily /handling/ all of them, help in this
discussion?
There is already an API which exposes all SFNT tables. Parsing
doesn't make sense at all: The SFNT tables are written for *live
access* (as done
The makers of m17n developed libotf which at a time provide some,
although rather spotty, support for complex-script rendering.
Is it really `spotty'? I've never tested it, but it seems that its
Lisp framework should easily handle all aspects, and in case errors
are found, m17n gets patched
WL Is it really `spotty'? I've never tested it, ...
Try (a modern version of) gnu emacs to give libotf a whirl.
I use it all the time, but I have no knowledge about complex scripts
like Arabic or Khmer.
Werner
___
Freetype-devel mailing
ttfautohint 0.93 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.93
Enjoy!
Werner
PS:
:) already tried that, plus re-cloning.
Exactly same error though.
Fixed in git. Thanks for the report.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
. If possible, please replace Computer Modern with another font
and double its size so that everything stays readable if I scale
down the image.
BTW, I've just seen that on CTAN the new package
tex-gyre-math
is available, providing math support for Pagella and Thermes (this is,
I replaced the CM font with the STIX one (most easy with
matplotlib).
OK.
http://webloria.loria.fr/~rougier/tmp/glyph-metrics-horizontal.pdf
http://webloria.loria.fr/~rougier/tmp/glyph-metrics-vertical.pdf
Thanks. A very minor thing: In `glyph-metrics-vertical.pdf', the word
`origin'
http://webloria.loria.fr/~rougier/tmp/glyph-metrics-horizontal.pdf
http://webloria.loria.fr/~rougier/tmp/glyph-metrics-vertical.pdf
It'd look lovely in color, but do not over do it. E.g., draw the
glyph in black, the axes in red, and the dimensions in blue.
Nice idea! But please not too
Here is a preliminary patch to permit a font WITHOUT essential
tables, if its header declares CFF/OpenType (by OTTO tag) and CFF
table is included.
Hmm, the demo font works without this your patch.
This patch does not use cmap table, it uses the character-glyph
mapping info (Encoding dict)
I was wondering what license concerns there might be over porting
FreeType 2 to C#.
Just use the same licenses as FreeType, and you are done.
I was also wondering if there would be a recommended path to
porting. Currently I planned on implementing the TTF driver to test
the port, and
What is the Freetype policy and/or goals with regard to integer
overflows?
Overflows should be avoided. If you need an exact bit width, use
FT_Int{16,32}. 64bit variables are nowhere used except in code
guarded with FT_LONG64 (however, the code should be written so that it
works with FT_Int
I think the most critical issue is which testing environment would
be best for FT. CUnit, CppUnit, googletest, ...
Since FreeType is written in C I suggest a test suite in C also. This
would exclude CppUnit and googletest.
In case you have experience with such tools, I would ask you to
Many of them are not freely available but are essential for
testing. Any idea how to handle this?
Like http://packages.debian.org/de/sid/ttf-mscorefonts-installer
Yes, this helps. However, a lot of fonts are not available this way.
I've received them privately via e-mail, and I must not
ttfautohint 0.94 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.94
Enjoy!
Werner
PS:
The problem is that I have a customized version of ftoption.h.
According to CUSTOMIZE, Just put your custom `ftoption.h' file into
the objects directory. When I do this sequence:
$ cd ~/work
$ cp jni-ftoption.h ~/work/ft2-jni/ftoption.h
$ cd ~/work/ft2-jni
$
Here's the suggestion, with a bonus tweak to INSTALL.CROSS. [...]
Thanks, committed!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Hello Alexei!
1) TT_MULDIV macros are replaced with to direct calls to FT_MulDiv
because they do not do anything useful
Good idea. Please commit this (as a separate patch).
2) TT_MulFix14 is now a macro that uses FT_MulFix, no need to
duplicate the code
Please be very careful here.
1) TT_MULDIV macros are replaced with to direct calls to FT_MulDiv
because they do not do anything useful
Good idea. Please commit this (as a separate patch).
Committed this as well as TT_DivFix14 changes..
Thanks!
Werner
___
ttinterp.c:2706: After checking if F_dot_P is smaller than a
threshold, it is assigned a maximum possible value rather than a
threshold value. Is it possible that there is one zero too many on
line 2706 and we meant to assign a threshold value?
I think the current code is correct: If the
May be need to reset the limit pointer:
t1parser.c: line 395:
Found:
parser-root.limit = parser-base_dict + parser-base_len;
T1_Skip_PS_Token( parser );
cur = parser-root.cursor;
limit = parser-root.limit;
Yin-Sen, thanks for the bug report and fix; I think
Folks,
I'll do a new release within the next few days. If there are any
comments, please make them now.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[I'm sending this to the ft-devel mailing list since `infinality.net'
seems to have e-mail problems. If you are not Erik or Alexei, you
might ignore it :-)]
Erik, Alexei!
First of all, thanks for working on the code :-)
Interesting... I thought there was a problem because I didn't see
Dear 晓明,
I've just stumbled across your old e-mail from April the 12th.
freetype-2.4.9\src\bdf\bdflib.c(772): warning C4244: “function”:
conversion from 'ptrdiff_t' to 'unsigned long',
possible loss of data
error = (*cb)( buf + start, end - start, lineno,
(void*)cb,
It seems OK, and it compiles fine.
Erik, please have a look at the attached patch. I've `beautified' the
bytecode opcodes, and I've discovered that most of them appear to be
incorrect, compared to the listings in
http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx
Please
Have you actually done binary searches in TTFs to find signatures?
Well, only using the code here, not with a hex editor. I have seen
hits in some TTF files where I would not have expected them. May
speak to the issues you mentioned below.
OK. So it's definitely worth some tests :-)
So, I've applied the updated patch you provided.
OK.
The adjusted opcode sequences for the spacing functions broke Segoe
UI Semibold (maybe others too), but I agree that what you did looks
correct for those.
I'm not completely sure whether the bytecode sequences are correct.
For example,
In your integrated code you use FT_UInt for the rule scaling factor,
with 1000 being a unit. This contradicts the general FreeType
practice of using FT_Fixed to represent fractional numbers. I would
strongly suggest switching to FT_Fixed, with 0x1 representing a
unit. Then all
I had originally been using floating point to handle stretching and
emboldening of glyphs, which for obvious reasons Werner didn't want.
So, I used 1000 because it was easier to convert to and from
percentage.
I'm OK converting all this over to FT_Fixed, however I think it will
make
That patch is to fix the problem that Freetype2 does not handle
the 3-axis MM font FontBBox correctly. What happens is freetype2
tries to read the 2nd FontBBox and freetype2 does not expect
there are 8 components for 3-axis MM font. So it chokes. In an
earlier freetype2
FreeType 2.4.11 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've completely redesigned FreeType's website, giving it a more recent
look to enhance readability and to make navigation easier.
Please note that only the two topmost levels have been changed yet;
the remaining pages will follow.
Enjoy!
Werner
This is the last in the series of today's three announcements, and the
most important for me personally.
I've started a pledgie campaign for FreeType development and
maintainance. While no single company employs me directly to work on
it, I am constantly improving it, adding new features,
I've started a pledgie campaign for FreeType development and
maintainance.
Oops, a fourth one, this time with the link to the pledgie site :-)
http://pledgie.com/campaigns/18808
Werner
___
Freetype-devel mailing list
I'm having the dickens of a time putting together a new
amalgamation. It seems afmodule.c uses the type
'FT_Properties_SetFunc', which is only declared if
FT_CONFIG_OPTION_PIC is set? But FT_CONFIG_OPTION_PIC is not set in
my configuration so I am getting a compile error.
Something is
I'm unable to duplicate the first issue you mentioned, regarding the
B/W text.
Ah, I forgot to tell you how to build. For a build with subpixel
hinting, simply I say
make devel
make
from a clean (unmodified) repository. For a build without subpixel
hinting, modify `devel/ftoption.h'
[
My e-mails sent directly to Erik are still undeliverable with
infinal...@infinality.net:
domain has no mail exchangers
Reason is, AFAIK, that my host checks the existence of
`infinality.net' only once (while trying to send), while a mailing
list retries many times until it gives up.
Well, I've been building the dynamic library and then using LD_PRELOAD
to reference it. I verified with ldd that it is in fact loading the
newly-compiled library. Still, I am unable to reproduce it.
Strange.
How would I go about running ftview once I have the static .a
library?
Let's
I'm unable to duplicate the first issue you mentioned, regarding
the B/W text. When I run ftview as you stated, and hit 'a', the
result is the same as your first picture, with the well-hinted
monochrome characters. So, something must be different between
our builds.
I see good
Del,
thanks for the test font.
That patch is to fix the problem that Freetype2 does not handle
the 3-axis MM font FontBBox correctly. [...]
Actually, FreeType didn't correctly handle any /FontBBox command
within a /Blend dictionary...
I've fixed that in the current git. Please
Hello Tobias!
In April you wrote the following:
I've encountered what seems to be a rendering bug with monochrome
rendering of capital M in the DroidSans font at large sizes. See
the attached image. I've tried both 2.4.8 and GIT head with
identical results.
Download DroidSans.ttf from
In git you can now find redesigned ftview and ftdiff demo programs
which now display all options. Additionally, the demo programs with a
graphical front-end support new command line options -w and -h to set
the window width and height, respectively.
Enjoy!
Werner
I just noticed that Freetype documentation frequently refers to
fixed float format or type. This is an oxymoron, of course. What
Freetype uses is fixed-point representation of real numbers using
integer types, as opposed to floating point representation using
float or double types. I would
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 ascent+descent=line-height, this property may not
hold anymore after hinting. ascent+descent may be off by one
pixel compared to
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.
Patch attached. Werner, feel like committing this?
Not yet, sorry. IMHO
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 internals are still available but no
longer activated by default. I've done
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?
Werner
___
Freetype-devel mailing list
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?
http://git.savannah.gnu.org/cgit
So, I think I have something that's roughly working on my system,
and still maintaining similar performance to native TT rendering.
Great!
I have created sph_fdef_flags inside of the TT_DefRecord, and
sph_in_func_flags and sph_found_func_flags inside of
TT_ExecContextRec.
This looks OK.
Looks like it currently only works for 1bit images. Patch attached.
Applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Attaching the docs diff.
I've applied them to the website (except for the reference which I
will regenerate with the next FreeType release), thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Well, I'm trying to set a variable inside the execution context
during Ins_FDEF that will set compatibility mode to on for the
rest of the execution of glyph hinting for that entire face.
OK.
I'm assuming that the FDEFs are only read once during the prep, and
not every time a glyph is
Ok, after more experimentation, it *does* detect and store
compatibility_mode correctly when I store it in the TT_Face
object. I am running into an odd issue with Firefox and TNR however.
For some reason, the patterns are not detected with Times New Roman
Regular. And I know that Ins_FDEF
I think I've figured out the issue here, and (huge surprise) it's
not firefox. I was making the detection of opcode patterns
dependent on ignore_x_mode being set, however this doesn't get set
until glyphs are loaded.
Doh. Yes, for speed reasons the parsing of tables is lazy, at least
Freetype encounters an error when open the embeded font. the error
code is 2.
I've extracted the font with pdftk, and the current git renders this
font just fine (and version 2.4.11 also works).
Werner
___
Freetype-devel mailing list
I wonder whether we should do the same for non-TrueType fonts. I
think yes, but please comment!
Are there any known TTF fonts where the hinting is impacted
(positively or negatively) by this change?
No, this change is not related to hinting at all. It affects *all*
TrueType fonts
I was just wondering if we have any examples of real-world, visual
impact of the change, whether that's on hinting or something else.
Oops, it's not
FT_Face-height
but
FT_Face-size-metrics-height
which gets computed differently now. Sorry for the confusion.
All programs which use
I wonder whether we should do the same for non-TrueType fonts. I
think yes, but please comment!
With TrueType fonts, one expects Windows-like behavior. With
others, one does not. That said, there is a virtue in consistency.
Either way, man.
If you look at the code for a single glyph,
This has been replaced with
ascender_int = round(ascender_26.6);
descender_int = round(descender_26.6);
height_int = ascender_int - descender_int;
This seems to assume that height_26.6 was always ascender_26.6 + -
descender_26.6. I'm not sure this is always true. IIRC, there are
1201 - 1300 of 3661 matches
Mail list logo
