Re: [ft-devel] [patch] fuller right margin in ftview
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: bad-emboldening.png___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ttfautohint] stem width handling is now selectable
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. You defending this more than just a heuristic value, there is a European pride behind it :) Indeed :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ttfautohint] stem width handling is now selectable
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-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ttfautohint] stem width handling is now selectable
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 particular, the TrueType language works with 26.6 entities, and Type 1 only support integer arguments for the `div' operator, so there are some good reasons for integer arithmetics... And most particular: I won't do such a conversion :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [autohint] improved handling of serif fonts
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 ttfautohint. Cf. this bug report: https://savannah.nongnu.org/bugs/index.php?func=detailitemitem_id=36091 Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] FT_MulFix_arm clobbers the condition codes, so specify cc in the clobber list.
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 mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [RFC PATCH] Fix strict-aliasing warning
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 https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint 0.91 has been released
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: Downloads from savannah.nongnu.org will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use http://download-mirror.savannah.gnu.org/releases/ -- This project provides a library which takes a TrueType font as the input, remove its bytecode instructions (if any), and return a new font where all glyphs are bytecode hinted using the information given by FreeType's autohinting module. The idea is to provide the excellent quality of the autohinter on platforms which don't use FreeType. The library has a single API function, `TTF_autohint'; see `lib/ttfautohint.h' for a detailed description. Note that the library itself won't get installed currently. A command-line interface to the library is the `ttfautohint' program; after compilation and installation, say ttfautohint --help for usage information, or say man ttfautohint to read its manual page. A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework. The compilation of this application can be disabled with the `--without-qt' configuration option. -- New in 0.91: * A new, `strong' routine to handle stem widths and positions has been added, to be selected with the `--strong-stem-width' command line option. If it is active, stem widths and positions are snapped to the grid as much as possible. This algorithm is useful for GDI ClearType support. * A new command line option `--debug' (not available for ttfautohintGUI) to print very detailed debugging information. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint - weird snapping with composite glyphs
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 snapping is fine. Ah, I can faintly remember this issue, but it vanished completely from my radar. I'm sure this glitch is known, so this is more of a reminder ;) Just for reference I ask you to give a specific example so that I can easily reproduce the problem. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] controlling FreeType modules
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
first draft of how an interface might look like. However, this is far
from sufficient, and it is special to the auto-hinter only, while we
need a more generic solution to control any module.
So here is another proposal for an interface.
Property service
Properties get accessed with FreeType services. For example, to
make the module `foo' listen to property changes, add a
`foo-properties' service to the module, with two functions to get
and set values.
Default properties
--
Internally, we use an `FT_Property' structure to collect all
properties in a linked list:
typedef FT_Property_
{
FT_String*module_name;
FT_String*property_name;
void* value;
FT_Property* next;
} FT_Property;
The list is located in the `FT_Library' object:
FT_Property* properties;
Allocation and deallocation of `properties' is handled by FreeType.
As soon as a new `FT_Face' object gets created, the corresponding
modules check the `properties' list and use it for initialization.
There might be properties which are not suitable for global
initialization; such cases are to be ignored (with a debugging
warning probably).
Already existing `FT_Face' objects are not affected.
FT_Error
FT_Library_SetProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Library_RemoveProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name );
FT_Error
FT_Library_GetProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* avalue );
The generic pointer `value' gets typecast to a pointer of the real
value variable or structure. Maybe not the most convenient, it
guarantees flexibility and extensibility, however.
Local properties
These are located in an FT_Face object. Existing values for
properties get overwritten.
FT_Error
FT_Face_SetProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Face_RemoveProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name );
FT_Error
FT_Face_GetProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name,
void* avalue );
Examples
/***/
/* Set property `bar' in module `foo' to value 1. */
FT_UInt bar;
bar = 1;
FT_Face_SetProperty( face, foo, bar, bar );
/***/
/* Get property `baz', which consists of a minimum and maximum */
/* value. */
typedef range_
{
FT_Int32 min;
FT_Int32 max;
} range;
range baz;
FT_Face_GetProperty( face, foo, baz, baz );
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint x-heights
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? :) Right now I'm thinking hard about this issue. 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. This is something I haven't taken into consideration until now. Reason of the vertical size increase is some vertical scaling the autohinter applies to the whole font so that the x height gets adjusted to the pixel grid. It's quite an elegant way to improve rasterization while having almost no glyph distortion. BTW, if you say `ttfautohint --help', you can see -X, --x-height-snapping-exceptions=STRING specify a comma-separated list of x-height snapping exceptions which is not implemented yet, but you would need exactly this option to avoid the effect you are observing. The problem is deep, since the usWin values always get rounded (and not floored and ceiled) to the pixel grid. It essentially means that hints must *always* stay within the area spanned up by the original outline (in font units) or some glyphs are cropped.[1] In particular, using a vertical scaling factor 1 inevitably leads to clipping. I'm not sure how to proceed, and any ideas are highly welcomed. Werner [1] Interestingly, Microsoft itself doesn't always obey that, cf. glyph U+01FA (Aringacute) in Arial (according to http://code.google.com/p/googlefontdirectory/wiki/VerticalMetricsRecommendations). ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint x-heights
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 integers was buggy. Since the fix (already in the git repository) considerably improves the appearance of a lot of fonts, I'll soon do a new release of ttfautohint. Anyway, the central question remains: What to do if hinting might exceed the usWin values (e.g. by using ttfautohint's -x option). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint x-heights
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 certain pt sizes. This is correct, and intentional. In general, the autohinter is increasing the glyph size much more often than decreasing. Remember that the original code in FreeType tries to hint the glyphs without any manual intervention at run-time. Compressing a font vertically might lead to very ugly results, while the opposite can only improve the appearance. However, ttfautohint doesn't hint at run-time, so I can try to make it better, and the forthcoming option -X (or a variant of it) is the right means for that. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint 0.92 has been released
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: Downloads from savannah.nongnu.org will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use http://download-mirror.savannah.gnu.org/releases/ -- This project provides a library which takes a TrueType font as the input, remove its bytecode instructions (if any), and return a new font where all glyphs are bytecode hinted using the information given by FreeType's autohinting module. The idea is to provide the excellent quality of the autohinter on platforms which don't use FreeType. The library has a single API function, `TTF_autohint'; see `lib/ttfautohint.h' for a detailed description. Note that the library itself won't get installed currently. A command-line interface to the library is the `ttfautohint' program; after compilation and installation, say ttfautohint --help for usage information, or say man ttfautohint to read its manual page. A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework. The compilation of this application can be disabled with the `--without-qt' configuration option. -- New in 0.92: * A serious bug in the created bytecode has been fixed, causing incorrect rounding. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint 0.92 has been released
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' uses. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Regression issue - CFF
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 for it, I can try to focus more time on the task. Yes, it would be nice if you could work on this. However, a malformed font is a malformed font. Actually, Ivan should send a bug report to Adobe IMHO... I don't think that the incorrect output of this Adobe tool is intended. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] Stroked Glyph Caching
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 https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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 be 2 ways: A) set-property function does not invoke the cache flusher, but sets some internal flags in FT_Library or FT_Face to indicate the change of the properties. when the cache is accessed, the cache manager checks the flag and flush if needed. B) put a list of FTC_Manager instance(s list) into FT_Library. if set-property functions are used, FT_Library instances invoke the cache flusher of the listed FTC_Manager instance(s). Which is better? What about C) If an application uses FreeType's cache system, it should call `FTC_Manager_Reset' to flush the cache. ? This sounds rather straightforward to me, and it fully avoids any internal hassles. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [bug #37017] Freetype 2.4.8 renders the Sabrina-AT font incorrectly.
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. :-) https://savannah.nongnu.org/bugs/index.php?37017 For reference, I'm attaching his patch below. In case you have Bézier harness tests, please run them! Alexei, please extend the comment so that normal mortals like me can better understand the mathematical logic behind your change, then apply it. Werner == diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c index a7a18f2..bb263fb 100644 --- a/src/smooth/ftgrays.c +++ b/src/smooth/ftgrays.c @@ -1082,10 +1082,8 @@ typedef ptrdiff_t FT_PtrDist; goto Split; /* If P1 or P2 is outside P0-P3, split the curve. */ -if ( dy * dy1 + dx * dx1 0 || - dy * dy2 + dx * dx2 0 || - dy * (arc[3].y - arc[1].y) + dx * (arc[3].x - arc[1].x) 0 || - dy * (arc[3].y - arc[2].y) + dx * (arc[3].x - arc[2].x) 0 ) +if ( dx1 * ( dx1 - dx ) + dy1 * ( dy1 - dy ) 0 || + dx2 * ( dx2 - dx ) + dy2 * ( dy2 - dy ) 0 ) goto Split; /* No reason to split. */ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] Stroked Glyph Caching
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: * FTC_Manager_New() - now takes an additional argument for the * number of FT_Stroker objects to cache. This is a problem, and I ask others to chime in for discussion. While the FreeType cache code is tagged as beta, I believe that many applications already use it. Additionally, its interface hasn't changed for a long time, so it is probably better to stay with it as-is. In general, I don't like the approach of FTC_Manager_New to specify maximum values for various objects. As your patch shows, it makes it virtually impossible to extend the cache functionality without breaking the API. Instead, I suggest to use properties, cf. this thread: http://lists.gnu.org/archive/html/freetype-devel/2012-07/msg00055.html http://lists.gnu.org/archive/html/freetype-devel/2012-08/msg00022.html What do you think? I'll soon start with coding the infrastructure. One thing I would note about the patch is the hash of a FTC_StrokerTypeRec just adds the data together. I don't think this is the best hash method, but hopefully you guys have some better ideas. Regarding myself, I don't have a better idea :-) Maybe there are people on this list who have more experience with that. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] Stroked Glyph Caching
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 think it is important to have a consist API so the user doesn't get confused. Of course. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] supporting coloured bitmaps in FreeType
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 to implement this? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] adjustable stroker radius
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 1000)? Right now, if increasing and decreasing the slant, ftview sometimes shows `-0.000' which looks weird. Using integer values, such rounding issues can be avoided completely. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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, not everything is wrong. This one Property service Properties get accessed with FreeType services. For example, to make the module `foo' listen to property changes, add a `foo-properties' service to the module, with two functions to get and set values. stays the same, while this Default properties -- Internally, we use an `FT_Property' structure to collect all properties in a linked list: [...] doesn't work. Fact is that modules can only be controlled at the FT_Library level; FT_Face objects simply use pointers into an FT_Library's module list. This has two consequences: (1) The suggested API is much simpler. (2) Changes to modules have an immediate effect to *all* FT_Face objects, including the ones already created. If you want to have FT_Face objects with different module settings, simply use another FT_Library object. If memory is a concern it is possible to only load selected modules into this new FT_Library object instead of the default ones, as discussed in the FreeType documentation. The intended API looks like this now FT_Error FT_Property_Set( FT_Librarylibrary, const FT_String* module_name, const FT_String* property_name, void* value ); FT_Error FT_Property_Get( FT_Librarylibrary, const FT_String* module_name, const FT_String* property_name, void**avalue ); which I'm going to implement the next few days. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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
because a FT library is destroyed, who's responsible for cleaning up
the pointed-to property data?
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.
property tends to bring to mind simple things like numeric or
string settings. Strings could I suppose passed directly; how about
numbers?
Here's a typical example. Let's say I want to control the range where
the auto-hinter rounds the hinted size more easily to larger integers.
typedef range_
{
FT_Int32 min;
FT_Int32 max;
} range;
range increase_x_height = { 6, 22 };
FT_Property_Set( library, autofitter, increase-x-height, range );
Another example is to get a pointer to the auto-hinter's internal
`glyph_script' array which holds a map between glyph indices and its
assigned scripts. The idea is to fix entries which need OpenType
support (for example, small caps or superscripts which are normally
not visible in the cmap).
typedef glyph_idx_to_script_
{
FT_Long count;
FT_Byte* scripts;
} glyph_idx_to_script;
void* v;
glyph_idx_to_script* map;
FT_Long idx;
FT_Property_Get( library, autofitter, glyph-to-script-map, v );
map = (glyph_idx_to_script*)v;
/* change an entry */
idx = 12;
if ( idx map-count )
map-scripts[idx] = AF_SCRIPT_LATIN;
Structures like `range' or `glyph_idx_to_script' are predefined.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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 couldn't pass in any
dynamically calculated values.
Yes.
But since (AFAICT) the property mechanism is generic, the type of
the data structure wouldn't be known except to the eventual caller
of FT_Property_Get. Given this, how can FT_Property_Set know the
size of the data structure passed in, to malloc/copy it?
The property mechanism has a generic interface to accept any data
structures so that it stays extensible, but the data structures
themselves aren't generic; they are always controlled by FreeType.
For example, to pass a string of arbitrary length, a possible
structure might be
struct foo
{
intlen;
char* str;
}
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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 soon as you are up to date with reading the FreeType email list postings, you will have seen my other email. Now there are only two functions, FT_Property_Set and FT_Property_Get. As a user of the library, I don't care about modules, services, or generic properties infrastructures. You don't have to. Services is something internal to FreeType, not visible by the application. The module API already exists, and it is central to FreeType, so I will continue with addressing properties using module names. Just give me an enum for the parameters that make sense, and a setter/getter. Hmm. Instead of an enum like FT_AUTOFITTER_DO_THIS_AND_THAT you will have to use two arguments, autofitter and do-this-and-that, so I don't see a big difference, neither in understanding nor typing. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Architecture Astronaut: Liftoff in 5, 4, 3...!
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 . switch on/off vertical hinting . switch on/off emboldening of small glyphs . control range of emboldening of small glyphs . ditto for thin glyphs . ditto for `more rounding up' . control glyph index - script mapping . ttf engine: . select interpreter version (this also controls whether we have GDI ClearType, DirectWrite ClearType, or none) . cache: . control maximum number of slots, faces, etc. ... Note that I don't want to have zillions of functions; instead I want two functions to set and get those values. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] TrueType 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 don't have time to bisect the source code to find out the commit which fixes the font, so I suggest that you upgrade to a more recent GhostScript version (which hopefully incorporates a newer FreeType version also). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
The intended API looks like this now
FT_Error
FT_Property_Set( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Property_Get( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void**avalue );
which I'm going to implement the next few days.
And here it is. FT_Property_Get is slightly different now, namely
FT_Error
FT_Property_Get( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* value )
A first property for the auto-hinter, `glyph-to-script-map' (without
documentation yet), is implemented too. An application would do
something like the following:
/* the format of this structure is specific */
/* to the `glyph-to-script-map' property*/
typedef struct map_property_
{
FT_Face face;
FT_Byte* map;
} map_property;
map_property prop;
FT_Init_FreeType(library);
FT_New_Face(library, foo.ttf, 0, face);
prop.face = face;
error = FT_Property_Get(library, autofitter,
glyph-to-script-map, prop);
/* now use OpenType features to fix the glyph to script mapping */
/* returned in prop.map array */
FT_Done_FreeType(library);
I think that the interface is stable now. Please comment.
Werner
diff --git a/include/freetype/fterrdef.h b/include/freetype/fterrdef.h
index fb4b53b..bb06d79 100644
--- a/include/freetype/fterrdef.h
+++ b/include/freetype/fterrdef.h
@@ -4,7 +4,7 @@
/* */
/*FreeType error codes (specification).*/
/* */
-/* Copyright 2002, 2004, 2006, 2007, 2010-2011 by */
+/* Copyright 2002, 2004, 2006, 2007, 2010-2012 by */
/* David Turner, Robert Wilhelm, and Werner Lemberg. */
/* */
/* This file is part of the FreeType project, and may only be used, */
@@ -56,6 +56,8 @@
array allocation size too large )
FT_ERRORDEF_( Missing_Module, 0x0B, \
missing module )
+ FT_ERRORDEF_( Missing_Property,0x0C, \
+missing property )
/* glyph/character errors */
diff --git a/include/freetype/ftmodapi.h b/include/freetype/ftmodapi.h
index 4cb089d..b0dc113 100644
--- a/include/freetype/ftmodapi.h
+++ b/include/freetype/ftmodapi.h
@@ -42,14 +42,15 @@ FT_BEGIN_HEADER
/*Module Management */
/* */
/* Abstract*/
- /*How to add, upgrade, and remove modules from FreeType. */
+ /*How to add, upgrade, remove, and control modules from FreeType.*/
/* */
/* Description */
/*The definitions below are used to manage modules within FreeType. */
/*Modules can be added, upgraded, and removed at runtime.*/
+ /*Additionally, some module properties can be controlled also. */
/* */
- /*Here is a list of module names (the possible values of the */
- /*`module_name' field in the @FT_Module_Class structure).*/
+ /*Here is a list of possible values of the `module_name' field in*/
+ /*the @FT_Module_Class structure.*/
/* */
/*{ */
/* autofitter */
@@ -72,6 +73,7 @@ FT_BEGIN_HEADER
/* winfonts */
/*} */
/* */
+ /*Note that the FreeType Cache sub-system is not a FreeType module. */
/* */
/*/
@@ -274,6 +276,130 @@ FT_BEGIN_HEADER
FT_Module module
Re: [ft-devel] controlling FreeType modules
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 for a spring cleaning? Since I'm very bad at API design, I won't start such a project, but you are very welcome to discuss potential improvements, and it's very cheap to start a new branch in the git repository. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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 that we're using a TTF in a PS/PDF/PCL/PXL context, we'll need a way to influence that behaviour. This sounds like a good candidate for a property of the truetype module... My preference is to have a dual level API: where you might have a simple high level interface, which includes the very simplest use cases and hides the vast majority of the details of what the library is doing from the calling app, and users need very little knowledge to use it. Then you have a low level API, where users need a lot more knowledge of what they're doing, but they then have the ability to access and influence a lot more of the behaviour of the library. But this doesn't solve the problem of exposing internal structures to the public... Also, a note on the fontconfig interaction mentioned: I'm not clear on what that proposal involves, but I would urge against Freetype interacting directly with fontconfig. I feel Freetype should continue to be purely a font scaling/rendering library, and shouldn't get involved in font management, or other peripheral functionality. Basically, I agree. However, the border between font objects and font management is fuzzy. For example, do you consider composite fonts like Windows 7's `CompositeFont' objects or PostScript's `FontType 0' fonts as something FreeType should handle? I think it doesn't really belong to FontConfig. Instead, I can imagine a layer on top of FreeType which handles such formats. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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 layout capabilities. Yes. But it's what one has to be done for CFR. otherwise someone needs to write another library to support CFR, which may has a lot of duplicate code to FreeType. Not necessarily. It shouldn't be too difficult to provide the necessary hooks so that a small library for handling composite font objects on top of FreeType can reuse FreeType's code. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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 structures for storing those things). But this doesn't solve the problem of exposing internal structures to the public... The reality is that it means that the low level API will likely extend over time - as folks identify new aspects they want to interrogate or influence, we add functions to handle those to the API. Correct. However, `extending' a low-level API means that I no longer can *change* it... Alternatively, we could go a bit object oriented, so (almost?) every internal structure includes an accessor function pointer (I'd make the accessor the first entry in every relevant structure). Hmm. Then we can change the internal representations any way we want, and just modify the accessor function to suit. Doing it this way may be something for FreeType 3. By Postscript Type 0, I assume you mean a CIDFont which has been composed with a CMap? Whatever. I'm referring to fonts with a FontType of 0, as described in section 5.10 of the PostScript Language Reference Manual. From a Ghostscript point of view, we handle all the Type 0 font stuff ourselves, so Freetype only ever sees the descendant fonts, but in general, I would consider combining the CIDFont with the CMap to be part of loading a font for use, so within Freetype's remit. Having said that, given that you need a Postscript interpreter to really handle CIDFont/CMap combinations in the general case, I can't imagine there being much demand for it, so that may well be moot. I can imagine to provide hooks into FreeType to handle that. 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 layout capabilities. Yes. But unfortunately the reality doesn't always allow to draw a clean border. As mentioned previously, I prefer a (thin) layer on top of FreeType. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] running configure
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 a recent GNU make? In case you are on Windows, are all files using CRLF line endings? Do all files and directories have read permissions? Besides that, I'm running out of ideas. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fw: running configure
---BeginMessage--- I finally figured it out - restoring the original Makefile helped because this time it ran configure from the build/unix directory. It took a few attempts (first time, make just ran configure in build/unix again, erasing everything, and I needed to add a make clean to get it to actually recompile everything. Might not have been necessary, but did not want a stray /usr/local in some string constant! Many thanks for looking! As I had not seen any comments from the list yet (read my own posting) I did not want to post again immediately - creating SPAM. regards, Michael 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 the following message root@x104:[/data/prj/freetype/freetype-2.4.10]./configure make: *** No rule to make target `setup'. Stop. Are you using a recent GNU make? In case you are on Windows, are all files using CRLF line endings? Do all files and directories have read permissions? Besides that, I'm running out of ideas. Werner ---End Message--- ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] first auto-hinter infinality patch added to git
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 possible with the original implementation). From the documentation: For ppem values in the range 6 = ppem = ‘increase-x-height’, round up the font's x height much more often than normally. If the value is set to 0, which is the default, this feature is switched off. Use this property to improve the legibility of small font sizes if necessary. FT_Library library; FT_Face face; FT_Prop_IncreaseXHeight prop; FT_Init_FreeType( library ); FT_New_Face( library, foo.ttf, 0, face ); FT_Set_Char_Size( face, 10 * 64, 0, 72, 0 ); prop.face = face; prop.limit = 14; FT_Property_Set( library, autofitter, increase-x-height, prop ); Along these lines it should be possible to add other auto-hinter extensions. Erik? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] first auto-hinter infinality patch added to git
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 ttfautohint with FreeType again so that the upper limit for ttfautohint's -x option gets removed. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] first auto-hinter infinality patch added to git
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 provide examples? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] freetype2 remove useless rm detection
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
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
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 with Behdad though that gasp *definitely* should be supported by FreeType. Basically, in the default grayscale rendering, it should actually be grayscale+monochrome as defined by gasp. In the default subpixel rendering, it should be subpixel+Y-smoothing as defined by gasp. The user should be able to override these (force grayscale or force monochrome) but gasp is definitely NOT external to glyph rendering, it's very *essential*. OK. So FreeType should obey the `gasp' table by default? Or should this be a new FT_LOAD flag? Or a rendering flag? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
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 by HarfBuzz). Everything else makes it far too clumsy, slow, and memory hungry. BTW, I got the impression that Vinnie's JUCE stuff puts all kerning pairs into a table or so. In case this is true, it is dead wrong for reasons outlined by Adam. (Something else: in this and similar discussions I don't hear anyone mentioning m17nlib for text layout, [...] I think that m17nlib has one single target: Emacs. Consequently, it uses Lisp code to control it. However, as has been stated, the developers don't have time, energy, or whatever to further develop it, and IIRC it has been suggested by its authors that Emacs eventually switches to Harfbuzz also. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
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 accordingly. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
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 list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint 0.93 has been released
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: Downloads from savannah.nongnu.org will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use http://download-mirror.savannah.gnu.org/releases/ -- This project provides a library which takes a TrueType font as the input, remove its bytecode instructions (if any), and return a new font where all glyphs are bytecode hinted using the information given by FreeType's autohinting module. The idea is to provide the excellent quality of the autohinter on platforms which don't use FreeType. The library has a single API function, `TTF_autohint'; see `lib/ttfautohint.h' for a detailed description. Note that the library itself won't get installed currently. A command-line interface to the library is the `ttfautohint' program; after compilation and installation, say ttfautohint --help for usage information, or say man ttfautohint to read its manual page. A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework. The compilation of this application can be disabled with the `--without-qt' configuration option. -- New in 0.93: * New option `--components' to treat components of composite glyphs separately. This greatly reduces the bytecode size. I'm waiting for reports whether this option works for most fonts; in case this is true I'm inverting the option, making it the default (and the old behaviour optional). * Full support of TTCs, this is, all subfonts get auto-hinted now. * The upper limit of the `--increase-x-height' option has been removed. * Drag-and-drop support in the GUI. * The TTY version of ttfautohint now acts like a (Unix) filter, this is, it accepts stdin and stdout as input and output, respectively. * Less memory consumption. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] error building ttfautohint from git source - fedora 17
:) 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
Re: [ft-devel] Glyph metrics figures on the website
. 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, Palatino and Times). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Glyph metrics figures on the website
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' overlaps with the arrow above. And another one, for both images: You've converted the `xMax' and `bearingX' labels to $x_max$ and $X_bearing$ (ditto for `y'). I think it is better to use $x_max$ and $x_bearing$ instead to avoid confusion. The uppercase `X' was only the result of camel-casing a variable name. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Glyph metrics figures on the website
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 colourful :-) I very much prefer pale colours and shades of gray to get a `serious' look. BTW, can you please give an URL for the source files of the two images? I would like to reduce the margins. And how do you create the PDFs? What about creating SVG images additionally? Today I think it's OK to directly embed SVGs into a web page, and the conversion from PDF to SVG is not optimal; at least not with inkscape. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unable to load OpenType font (test case + font attached)
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) in CFF table. It is NOT expected behaviour, because CID-keyed CFF font for CJK scripts has no Encoding dict. I have to work more about... AFAIK, PDF drivers include CFFs in `pure' format if they don't need or want to use a cmap. I'm not sure it makes sense to support a CFF in SFNT format without a real `cmap' table. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Porting to C#/Mono
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 implement other formats as the need grows. This sounds like a good idea. If you are done please tell us! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype limits or integer overflows
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 having a width of 64 bits). If you really need
64bit intermediate precision, you should use FT_MulDiv and friends.
How practical are the large sizes that push outline dimensions
beyond 16 bits, or pixel size of 1024?
They can happen. At 600dpi, a glyph with a height of two inches (as
might happen in a newspaper headline) has a pixel size of 1200. Given
that recent screens for tablets have resolution up to 400dpi, it is
more important than ever that large pixel sizes work OK.
In a few places I see 64-bit arithmetic utilized to control the
overflow by means of FT_Int64. This integer type is not even
documented.
They are local to the ftcalc.c module. And the stuff in fttrigon.c is
wrong, but gets never compiled due to an incorrect #ifdef. I'll fix
that.
When is it ok to use this type?
Only in ftcalc.c, and you have to write two versions for use with and
without FT_LONG64.
For example, when I calculate a dot product of 2 vectors, which is a
very basic task. If dimensions are limited to 16-bits, the dot
product would fit into 32 bits, so there is no need to worry about
the overflow here.
Exactly. However, to multiply two 32bit entities, you need something
better, and 26.6 and 16.16 data types are frequently used.
If you *really* need some special computation with 64bit
intermediates, please add a function to ftcalc.c.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unit test environment for FreeType
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 set up the environment (stored in a git repository), possibly adding a few tests, and others (including me) could then easily add more tests. Note, however, that the greatest problem is probably the use of test fonts. Many of them are not freely available but are essential for testing. Any idea how to handle this? It's not just unit testing that's lacking, but nightly automated builds on a variety of platforms. Something that produces results like this: http://open.cdash.org/index.php?project=CMake Same issue as above. Any help would be highly appreciated! BTW, I recently encountered http://www.snakebite.net but this seems to provide Unix-like hosts only. But I presume that google also has a build farm; maybe this could be used? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unit test environment for FreeType
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 distribute them. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint 0.94 has been released
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: Downloads from savannah.nongnu.org will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use http://download-mirror.savannah.gnu.org/releases/ -- This project provides a library which takes a TrueType font as the input, remove its bytecode instructions (if any), and return a new font where all glyphs are bytecode hinted using the information given by FreeType's autohinting module. The idea is to provide the excellent quality of the autohinter on platforms which don't use FreeType. The library has a single API function, `TTF_autohint'; see `lib/ttfautohint.h' for a detailed description. Note that the library itself won't get installed currently. A command-line interface to the library is the `ttfautohint' program; after compilation and installation, say ttfautohint --help for usage information, or say man ttfautohint to read its manual page. A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework. The compilation of this application can be disabled with the `--without-qt' configuration option. -- New in 0.94: * New option `--windows-compatibility' which adds two artificial blue zones at vertical positions given by `usWinAscent' and `usWinDescent'. This helps ttfautohint's hinting algorithm reduce the possibility of clipping if those two values are very tight. * Implement option `--x-height-snapping-exceptions', making ttfautohint avoid x-height snapping for selected PPEM values. Useful in combination with `--windows-compatibility'. * Minor fixes to the created bytecode for compatibility and robustness. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Configuring for alternative build environments
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 $ ~/ft2/freetype2/configure CFLAGS=-fPIC $ make My customized version of ftoption.h disappears! Oops. This is a bug. I've just fixed it in the git repository. Thanks for the report, and please retry! Related: CUSTOMIZE seems silent on the handling of modules.cfg in this scenario of building outside of the FT source tree. Can you suggest a patch to CUSTOMIZE? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Configuring for alternative build environments
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
Re: [ft-devel] [patch] clean up MulDiv in bytecode interpreter
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. David has explicitly introduced this function *after* the standard FT_MulDiv functions, so there must be a reason (which unfortunately is not documented in the ChangeLog). Note that this function is used extremely frequently in bytecode, so maybe it contains subtle optimizations not easily recognizable; David is very good in handling this, he even compared assembler output of various compilers to the optimize C code. My gut feeling is to not change the code. It's just a few bytes more. However, I like the introduction of the FT_DivFix14 macro. 3) FT_MulFix and FT_DivFix are called when they are meant to be called, rather than using 0x1L explicitly Looks good. However, please provide a separate patch for easier review. 4) scaling by 64 is hardly an easy overflow trigger, so we can risk direct arithmetic, IMHO Well, I think you are wrong. Besides this, using direct arithmetics hides the `no round' issue. So I rather dislike this change. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] clean up MulDiv in bytecode interpreter
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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] scale F_dot_P down
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 value gets too small, use a (possibly large) default value which essentially disables the transformation. ttobjs.c:767: F_dot_P seems to be initialized to a tiny tiny value that is actually much smaller than the above threshold. It looks arbitrary when compared to the rest of F_dot_P usage instances with huge unscaled F_dot_P. Please check. As far as I can see, this initialization is not necessary at all, since F_dot_P gets always computed in line 8149 before any bytecode is run. Perhaps a compiler has complained about a missing initialization, and an arbitrary value (without a deeper look at the code) has been assigned in line 767. About the patch, whenever we use F_dot_P in the bytecode interpreter in comparisons or divisions we have to scale up the other side by 0x1L. I propose that instead we scale F_dot_P down by 0x1L when we assign it. This improves readability and avoids huge numbers and confusions with number of zeros. Please review the attached patch. I think it's better to not apply this patch. Reasons: (1) You are stripping off 16 bits of F_dot_P's precision. Or am I missing something? Pixel positioning in the TT interpreter is extremely sensitive to rounding; even smallest changes in the code might cause pixel shifts. Maybe such fixes/changes can be played with after we have a test suite which does a lot of pixel comparisons, but right now we don't have one. (2) FT_MulDiv and friends can handle 64bit precision internally, so I don't see a problem here with large numbers. And there is the abovementioned check in line 2706 to avoid too small values which would make the division overflow. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype render issue
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 this is the right one, so I have it committed to the git repository. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] new release soon
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
Re: [ft-devel] New Infinality Release
[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 anything updating on the Savannah end. Looks like while I was typing my last email, things showed up and appear to be OK. Werner, can you verify that everything is OK? Hope I didn't mess anything up. :) It seems OK, and it compiles fine. To avoid such problems in the future I ask you to always do git pull before saying git commit . And in case there is a long delay between committing and pushing, you should call git pull again right before git push so that you can resolve conflicts easily. This still doesn't completely prevent concurrent commits, but it reduces the time frame within this can happen to a few minutes. Hey! You're breaking my commit! :) Just about to fix that stuff. Can you put it back? No, he can't :-) Note that due to having a ChangeLog file, git's `rebase' functionality will fail usually. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Build freetype2 64bit in windows
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, client_data ); Fixed. freetype-2.4.9\src\base(39): warning C4306: “function”: conversion from ' int ' to ' FT_Pointer ' of greater size if ( svc == FT_SERVICE_UNAVAILABLE ) // this line: FT_SERVICE_UNAVAILABLE is defined to ((FT_Pointer)-2) I think I've fixed this and similar issues by using the `logical not' operator (~) instead of a negative value. Please test the current git. freetype-2.4.9\src\type1\t1load.c(618): warning C4244: “function”: conversion from 'FT_PtrDist' to 'FT_Long', possible loss of data if ( FT_ALLOC( blend-axis_names[n], len + 1 ) ) Fixed. If you still get warnings please send the complete output to the list. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
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 check that. Have you actually done binary searches in TTFs to
find signatures? Another possibility is to disassemble the `fpgm'
table with TTX, then doing a textual search (`pcregrep' might help for
multiline searches).
Additionally, ttfautohint's bytecode signature has changed; the new
one is
PUSHB_1,
32,
ADD,
FLOOR,
in function 0.
Given that the new ttfautohint bytecode signature is that short, as
are some other snippets in Greg's whitepaper, I think it is best if
you extend the code so that the function number is also checked to
avoid false hits.
Werner
diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index 505168d..440d385 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -4610,25 +4610,90 @@
FT_ULong n;
TT_DefRecord* rec;
TT_DefRecord* limit;
+
#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
FT_Byteopcode_pattern[7][12] = {
- /* inline delta function 1 */
- {0x4B,0x53,0x23,0x4B,0x51,0x5A,0x58,0x38,0x1B,0x21,0x21,0x59},
- /* inline delta function 2 */
- {0x4B,0x54,0x58,0x38,0x1B,0x5A,0x21,0x21,0x59,},
- /* diagonal stroke function */
- {0x20,0x20,0x40,0x60,0x47,0x40,0x23,0x42,},
- /* VacuFormRound function */
- {0x45,0x23,0x46,0x60,0x20,},
- /* ttfautohinted */
- {0x20,0x64,0xb0,0x60,0x66,0x23,0xb0,},
- /* spacing functions */
- {0x01,0x41,0x43,0x58,},
- {0x01,0x18,0x41,0x43,0x58,},
+ /* #0 inline delta function 1 */
+ {
+ 0x4B, /* PPEM*/
+ 0x53, /* GTEQ*/
+ 0x23, /* SWAP*/
+ 0x4B, /* PPEM*/
+ 0x51, /* LTEQ*/
+ 0x5A, /* AND */
+ 0x58, /* IF */
+ 0x38, /* SHPIX */
+ 0x1B, /* ELSE*/
+ 0x21, /* POP */
+ 0x21, /* POP */
+ 0x59 /* EIF */
+ },
+ /* #1 inline delta function 2 */
+ {
+ 0x4B, /* PPEM*/
+ 0x54, /* EQ */
+ 0x58, /* IF */
+ 0x38, /* SHPIX */
+ 0x1B, /* ELSE*/
+ 0x21, /* POP */
+ 0x21, /* POP */
+ 0x59 /* EIF */
+ },
+ /* #2 diagonal stroke function */
+ {
+ 0x20, /* DUP */
+ 0x20, /* DUP */
+ 0xB0, /* PUSHB_1 */
+ 0x01, /* 1 */
+ 0x60, /* ADD */
+ 0x46, /* GC_cur */
+ 0xB0, /* PUSHB_1 */
+ 0x40, /* 64*/
+ 0x23, /* SWAP*/
+ 0x42 /* WS */
+ },
+ /* #3 VacuFormRound function */
+ {
+ 0x45, /* RCVT*/
+ 0x23, /* SWAP*/
+ 0x46, /* GC_cur */
+ 0x60, /* ADD */
+ 0x20, /* DUP */
+ 0xB0, /* PUSHB_1 */
+ 0x26, /* 38*/
+ },
+ /* #4 TTFautohint bytecode (old) */
+ {
+ 0x20, /* DUP */
+ 0x64, /* ABS */
+ 0xB0, /* PUSHB_1 */
+ 0x20, /* 32*/
+ 0x60, /* ADD */
+ 0x66, /* FLOOR */
+ 0x23, /* SWAP*/
+ 0xB0 /* PUSHB_1 */
+ },
+ /* #5 spacing function 1 */
+ {
+ 0x01, /* SVTCA_x */
+ 0xB0, /* PUSHB_1 */
+ 0x18, /* 24*/
+ 0x43, /* RS */
+ 0x58 /* IF */
+ },
+ /* #6 spacing function 2 */
+ {
+ 0x01, /* SVTCA_x */
+ 0x18, /* RTG */
+ 0xB0, /* PUSHB_1 */
+ 0x18, /* 24*/
+ 0x43, /* RS */
+ 0x58 /* IF */
+ },
};
FT_UShort opcode_patterns = 7;
-FT_UShort opcode_pointer[7] = {0,0,0,0,0,0,0};
-FT_UShort opcode_size[7]= {12,9,8,5,7,4,5};
+FT_UShort opcode_pointer[7] = { 0, 0, 0, 0,
Re: [ft-devel] New Infinality Release
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 :-)
[...] I think it is best if you extend the code so that the
function number is also checked to avoid false hits.
Yes, this makes sense for functions where we know the number, such
as ttfautohint and 0.
Well, most of the bytecode snippets are associated with one or more
fixed function numbers.
But, I think the whitepaper states that on (at least some)
functions, the number varies, which is why you need the detection
code in the first place.
Correct. My concern is that we get false hits due to the shortness of
the snippets.
Regarding the problems with the opcode patterns, what did you see
that was incorrect? From scanning them (quickly) it seemed like it
was mostly correct (perhaps missing the end IF, etc.)
Ah, I see that I've done a mistake, below is a corrected patch
(untested). However, I think that the current method is flawed in
general since arguments to opcodes are completely ignored by
`SKIP_Code'. For example, it is not possible to decide whether the
bytecode is
SVTCA_x
PUSHB_1
24
RS
IF
or
SVTCA_x
PUSHB_1
39
RS
IF
It seems to me that we really have to compare the *complete* bytecode
(including the arguments) within `Ins_FDEF'.
Werner
diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index 505168d..ebd433c 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -4610,25 +4610,91 @@
FT_ULong n;
TT_DefRecord* rec;
TT_DefRecord* limit;
+
#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
+/* arguments to opcodes are skipped by `SKIP_Code' */
FT_Byteopcode_pattern[7][12] = {
- /* inline delta function 1 */
- {0x4B,0x53,0x23,0x4B,0x51,0x5A,0x58,0x38,0x1B,0x21,0x21,0x59},
- /* inline delta function 2 */
- {0x4B,0x54,0x58,0x38,0x1B,0x5A,0x21,0x21,0x59,},
- /* diagonal stroke function */
- {0x20,0x20,0x40,0x60,0x47,0x40,0x23,0x42,},
- /* VacuFormRound function */
- {0x45,0x23,0x46,0x60,0x20,},
- /* ttfautohinted */
- {0x20,0x64,0xb0,0x60,0x66,0x23,0xb0,},
- /* spacing functions */
- {0x01,0x41,0x43,0x58,},
- {0x01,0x18,0x41,0x43,0x58,},
+ /* #0 inline delta function 1 */
+ {
+ 0x4B, /* PPEM*/
+ 0x53, /* GTEQ*/
+ 0x23, /* SWAP*/
+ 0x4B, /* PPEM*/
+ 0x51, /* LTEQ*/
+ 0x5A, /* AND */
+ 0x58, /* IF */
+ 0x38, /* SHPIX */
+ 0x1B, /* ELSE*/
+ 0x21, /* POP */
+ 0x21, /* POP */
+ 0x59 /* EIF */
+ },
+ /* #1 inline delta function 2 */
+ {
+ 0x4B, /* PPEM*/
+ 0x54, /* EQ */
+ 0x58, /* IF */
+ 0x38, /* SHPIX */
+ 0x1B, /* ELSE*/
+ 0x21, /* POP */
+ 0x21, /* POP */
+ 0x59 /* EIF */
+ },
+ /* #2 diagonal stroke function */
+ {
+ 0x20, /* DUP */
+ 0x20, /* DUP */
+ 0xB0, /* PUSHB_1 */
+ /* 1 */
+ 0x60, /* ADD */
+ 0x46, /* GC_cur */
+ 0xB0, /* PUSHB_1 */
+ /* 64*/
+ 0x23, /* SWAP*/
+ 0x42 /* WS */
+ },
+ /* #3 VacuFormRound function */
+ {
+ 0x45, /* RCVT*/
+ 0x23, /* SWAP*/
+ 0x46, /* GC_cur */
+ 0x60, /* ADD */
+ 0x20, /* DUP */
+ 0xB0 /* PUSHB_1 */
+ /* 38*/
+ },
+ /* #4 TTFautohint bytecode (old) */
+ {
+ 0x20, /* DUP */
+ 0x64, /* ABS */
+ 0xB0, /* PUSHB_1 */
+ /* 32*/
+ 0x60, /* ADD */
+ 0x66, /* FLOOR */
+ 0x23, /* SWAP*/
+ 0xB0 /* PUSHB_1 */
+ },
+ /* #5 spacing function 1 */
+ {
+ 0x01, /* SVTCA_x */
+ 0xB0, /* PUSHB_1 */
+
Re: [ft-devel] New Infinality Release
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, Greg sometimes writes #PUSH[], 1 instead of the expected #PUSH 1 This might indicate that the command is actually using NPUSHB 0x01 0x01 instead of PUSHB_1 0x01, or even NPUSHW 0x01 0x00 0x01, but the latter is rather unlikely, so this needs more investigation and pattern searching in real fonts. If you provide me a script or whatever to do such a search, I can use my collection of old fonts as a testbed to search for hits. BTW, what do you think of replacing SPH_DEBUG with FT_TRACE7(( ... )) to get those information with FT2_DEBUG=ttinterp:7 ftview ... ? In case you are not acquainted with FreeType's tracing mechanism, have a look into docs/DEBUG. This, along with the point you mentioned above about not being able to detect the pushed value, makes me think that this piece needs more work before it gets pushed out to a release. I do want to keep one or two of them in there however. I will trim down the code to patterns known to be OK, and push off work on the others until after the release. Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
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 arithmetic will follow naturally with FT_MulFix, and FT_DivFix. +1 Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
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 maintaining it more confusing and tedious. Essentially, it's just a question of representation, not changing the values themselves. Good comments help :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patch to t1load.c to handle 3-axis Multimaster fonts
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 version, it does not have this issue because it does not read this 2nd FontBBox. So the patch is to skip the 2nd time action and then freetype2 is happy. As far as I can see, such 2nd time FontBBox read is not needed for our usage. So can we make this into the main line? Maybe not... The real fix is deeper than this patch addresses. My 2 cents. I am not currently in tune with the FreeType source, so I don't have a deeper fix at hand. But I offer this patch to illustrate our current workaround. Sorry if that's a tad lame - there's only so many hours in a day. Thanks for that. However, a detailed analysis is only possible with a demo font which exhibits the problem. If you can send it (privately to me, if necessary), this would help a lot. For this reason, I can't include the patch in version 2.4.11 (which I'll release today), sorry. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType 2.4.10 has been released
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; all users should upgrade. Enjoy! Werner PS: Downloads from savannah.nongnu.org will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use http://download-mirror.savannah.gnu.org/releases/ -- FreeType 2 is a software font engine that is designed to be small, efficient, highly customizable, and portable while capable of producing high-quality output (glyph images) of most vector and bitmap font formats. Note that FreeType 2 is a font service and doesn't provide APIs to perform higher-level features, like text layout or graphics processing (e.g., colored text rendering, `hollowing', etc.). However, it greatly simplifies these tasks by providing a simple, easy to use, and uniform interface to access the content of font files. FreeType 2 is released under two open-source licenses: our own BSD-like FreeType License and the GPL. It can thus be used by any kind of projects, be they proprietary or not. -- CHANGES BETWEEN 2.4.10 and 2.4.11 I. IMPORTANT BUG FIXES - Some vulnerabilities in the BDF implementation have been fixed. Users of this font format should upgrade. II. IMPORTANT CHANGES - Subpixel hinting support has been contributed by Infinality, based on Greg Hitchcock's whitepaper at http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx Originally, it was a separate patch available from http://www.infinality.net/blog/ and which has been integrated. Note that ClearType support is not completely implemented! In particular, full support for the options `compatible_widths', `symmetrical_smoothing, and `bgr' (via the GETINFO bytecode instruction) is missing. Activation of subpixel hinting support can be controlled with the `TT_CONFIG_OPTION_SUBPIXEL_HINTING' configuration option; it is switched off by default. This feature is still experimental; we welcome test reports! - Support for OpenType collections (OTC) has been added. - Pure CFF fonts within an SFNT wrapper are now supported. III. MISCELLANEOUS - Minor rendering improvements to the auto-hinter. - `FT_GlyphSlot_Oblique' now uses a shear angle of 12°. - Experimental support to handle `property modules', for example to control the behaviour of the auto-hinter. The API consists of two new functions, `FT_Property_Set' and `FT_Property_Get'. The code is still subject to change and should not be used for production. - The `ftdiff' demo program now supports UTF-8 encoded input files for option `-f'. - Using keys `r' and `R', you can now adjust the stroker radius in the `ftview' demo program. - Other, minor fixes and improvements. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType's webpage redesigned
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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Pledgie Campaign for Development and Maintainance
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, relentlessly driving up quality, and responding to other developers’ requests. Just have a look into the git repository or check my responses on the mailing lists to see what I do :-) If you or your company is using FreeType in your product, and you care about continuing support and further development, please contribute to my funding effort so I can continue to bring the best text rendering to your devices! Merry Christmas to all of you! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Pledgie Campaign for Development and Maintainance
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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2.4.11 amalgamation
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 apparently broken for you. The prototype for `FT_Properties_SetFunc' can be found in the new header file `include/freetype/internal/services/svprop.h', the pointer `FT_Service_Properties' to the `FT_Service_Properties_Rec' structure (which holds `set_property' and `get_property') is also defined there. All of this is outside of an FT_CONFIG_OPTION_PIC block. Maybe you are missing the file `svprop.h'? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
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' (*not* `include/freetype/config/ftoption.h!) and comment out TT_CONFIG_OPTION_SUBPIXEL_HINTING. Then do again `make devel; make'. This creates static builds, making sure that you don't access the wrong DLL accidentally. FontConfig is not involved at all. Regarding the second issue, with speed, I am able to dupliate it with arial.ttf, but the ratio is 4:1 instead of 14:1. The above development builds are unoptimized, maybe this explains the difference. I've kind of been hiding behind the fact that they glyph bitmaps get cached after the first run, and load quickly thereafter. :) Hehe. I'll see what I can do. Have you already done profiling with gprof or similar tools? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
[ 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. Any idea whether I can improve this on my side? Or is this only Erik's problem? Werner ] ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
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 assume that you've built FreeType in directory `freetype2' with `make devel; make', and let's assume that the demo package is in directory `freetype2-demos'. Then simply do cd freetype2-demos make to get static builds of the demo programs. Then repeat the whole process of building FreeType and the demo programs with the subpixel hinting macro disabled (after saving the just created binaries, of course). BTW, I'm using a 32bit GNU/Linux box. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
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 results in ftview unless I turn on forced autohinting, then
some of the stems are one pixel wider than the majority of the stems.
So, try hitting f to duplicate.
Hmm, with auto-hinting active it is rather *expected* to get bad B/W
hinting, so this is the wrong route.
Attached is a script which builds FreeType with and without subpixel
hinting in development mode (from the git repositories), then taking
snapshots in B/W mode. While testing the script, I've used Windows 7's
arial.ttf (version 5.10), but the results are the same as before.
You need `xdotool' and ImageMagick, BTW.
Werner
#!/bin/sh
#
# Using X11, make two snapshots from `ftview' in B/W mode, with and without
# compile-time macro TT_CONFIG_OPTION_SUBPIXEL_HINTING.
#
# This script uses the FreeType git repositories, compiling the programs
# with development options in a temporary directory (`fttest.XXX').
#
# You need the `xdotool' program to send X11 keyboard events and to get
# Window IDs (note that some versions of `xdotool' are buggy, not correctly
# understanding the `--pid' option; it is thus assumed that there is no
# ftview window opened when running this script)
#
# Images are created with ImageMagick's `import' tool; after the script has
# finished, you can find them in the top level of the temporary directory.
# Adjust to your setup.
FT2_REP=/home/wl/git/freetype/freetype2
FT2_DEMO_REP=/home/wl/git/freetype/freetype2-demos
FONT=/usr/local/backup/Fonts Windows 7/ttf/arial.ttf
IMG=`basename $FONT .ttf`
T=`mktemp -d fttest.XXX` || exit 1
D1=$T/without-subpixel-hinting
D2=$T/with-subpixel-hinting
git clone -l -s $FT2_REP $D1/freetype2
git clone -l -s $FT2_DEMO_REP $D1/freetype2-demos
(
cd $D1/freetype2
mv devel/ftoption.h devel/ftoption.h.orig
sed 's|\(#define TT_CONFIG_OPTION_SUBPIXEL_HINTING\)|/* \1 */|' \
devel/ftoption.h.orig \
devel/ftoption.h
make devel
make
cd ../freetype2-demos
make
cd ../..
without-subpixel-hinting/freetype2-demos/bin/ftview 15 $FONT
sleep 1
WID=`xdotool search --name FreeType Glyph Viewer`
xdotool key --window $WID a
sleep 1
import -silent -window $WID ${IMG}-without-subpixel-hinting.png
sleep 1
xdotool key --window $WID q
)
git clone -l -s $FT2_REP $D2/freetype2
git clone -l -s $FT2_DEMO_REP $D2/freetype2-demos
(
cd $D2/freetype2
make devel
make
cd ../freetype2-demos
make
cd ../..
with-subpixel-hinting/freetype2-demos/bin/ftview 15 $FONT
sleep 1
WID=`xdotool search --name FreeType Glyph Viewer`
xdotool key --window $WID a
sleep 1
import -silent -window $WID ${IMG}-with-subpixel-hinting.png
sleep 1
xdotool key --window $WID q
)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patch to t1load.c to handle 3-axis Multimaster fonts
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 test. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Monochrome DroidSans captital M rendering bug at large sizes
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 the Android GIT, or from this mirror: http://omapzoom.org/?p=platform/frameworks/base.git;a=blob_plain;f=data/fonts/DroidSans.ttf;hb=HEAD Run ftview like this: ftview -m M 352 DroidSans.ttf then disable antialiasing with the 'a' key. This seems to be fixed in release 2.4.11. Please test. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Improved demo programs
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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] fixed float
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 suggest fixing documentation: s/fixed float/fixed-point/g Objections? Of course not! Please go on. In case you are checking the web pages also, please send me diffs so that I can apply them to the git repository (which unfortunately is not set up on freedesktop.org -- I'm just sending a reminder). Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rounding of ascent, descent, and line height
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 line-height, which is not quite desirable. If I understand correctly that equality is broken only in the broken fonts. Really? I don't think so. I thought it happens because FreeType separately rounds ascent, descent, and line_height. From the bug: #ifdef GRID_FIT_METRICS metrics-ascender= FT_PIX_CEIL( FT_MulFix( face-ascender, metrics-y_scale ) ); metrics-descender = FT_PIX_FLOOR( FT_MulFix( face-descender, metrics-y_scale ) ); metrics-height = FT_PIX_ROUND( FT_MulFix( face-height, metrics-y_scale ) ); metrics-max_advance = FT_PIX_ROUND( FT_MulFix( face-max_advance_width, metrics-x_scale ) ); #else /* !GRID_FIT_METRICS */ Exactly this is the problem which I have to analyze. For TrueType fonts, the above code shouldn't be executed (or shouldn't have any influence). The function to execute instead is `tt_size_reset' in `src/truetype/ttobjs.c'), which uses ROUND, not CEIL or FLOOR. It seems that this doesn't get applied. So have you tried just forcing it? metrics-height = metrics-ascender + metrics-descender; The values get rounded first... If the height is more trustworthy, force the ascender: metrics-ascender = metrics-height + metrics-descender; In presence of an `OS/2' font table, global ascender and descender values are not derived, so your suggestion is not applicable for the font in question. Webkit did end up working around it. I was being a good citizen and bringing up the issue upstream. Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttsbit.c vs ttsbit0.c
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 the first step for the next release is to comment out the line #define FT_CONFIG_OPTION_OLD_INTERNALS in `ftoption.h' so that the old internals are still available but no longer activated by default. I've done that right now. A few months later we can then remove the code completely. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttsbit.c vs ttsbit0.c
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 that right now. A few months later we can then remove the code completely. And please open a bug tracking issue so that we don't forget it! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttsbit.c vs ttsbit0.c
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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttsbit.c vs ttsbit0.c
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/freetype/ Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
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. As soon as you have a patch (or maybe you want to create a branch so that others can test it also) I can give better comments. I'm looking forward to seeing this new code! There's still more to do, because some parts of the paper are vague. Maybe I'll make a list of things that are unclear and we can send it to Greg. OK. There haven't been many breakthroughs yet as far as eliminating tweak rules goes (although some rules may be able to go away soon). But I'm hoping that better approximating what is in the whitepaper can lead me there. Thanks for all your work. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fix for optimized sbit loader
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
Re: [ft-devel] fixed float
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 https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
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 loaded. Yes. But, it seems (yes, a vague word) like compatibility mode isn't always on during execution, even though I know that the function opcode patterns were triggered, and compatibility_mode was set to TRUE for that execution context. Have you tried to insert some debugging messages to check your problem? So, that makes me wonder if my assumptions about the execution context are even correct. Like, let's say that Times New Roman gets loaded, and Ins_FDEF detects that compatibility_mode should be set to TRUE. I set it as such, and then, Oxygen gets loaded, which sets compatibility_mode to FALSE, because it's a modern font without the triggering opcode patterns. You can only load a single font into an FT_Face structure. In real life, there are multiple faces used in parallel, managed by higher-level libraries. Then, I load another glyph from Times New Roman. Will the execution context for that glyph have compatibility_mode set to TRUE or FALSE? It *must* be TRUE in the FT_Face object which holds Times New Roman. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
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 is being executed because I used debug messages. Perhaps I'll have to be even more verbose with the messages. I have not seen this problem with any other face I've tested, and it only happens in firefox. Any ideas what might cause that? Is it possible that firefox is doing something incorrectly? Maybe FontConfig has set up Times New Roman on your box to use auto-hinting? A bug in Firefox is also possible, of course... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
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 partially. I'm just going to allow opcodes to be detected simply if TT_CONFIG_OPTION_SUBPIXEL_HINTING has been defined. Then, compatibility_mode will get enabled during runtime whenever the rendering mode isn't mono. Sounds reasonable. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype openface error
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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] heads-up: TrueType height computation has been fixed
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 regardless of hinting. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] heads-up: TrueType height computation has been fixed
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 this value are affected, for example ftview. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] heads-up: TrueType height computation has been fixed
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, `ft_glyphslot_grid_fit_metrics' in `ftobjs.c', you can see that we indeed add ceiled and floored values. However, for the global size metrics (in function `ft_recompute_scaled_metrics'), we don't do that... On the other hand, David is right: For some non-TrueType font formats, `height' is not always `ascender - descender' (cf. cffobjs.c:752, for example). So probably the current behaviour is the right one, or we indeed add the guard David has suggested. Tricky, tricky. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] heads-up: TrueType height computation has been fixed
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 fonts where the line height is actually different from ascender - descender, they would be affected by this patch in surprising ways. *blush* Uh, oh, I misunderstood what FreeType's `height' value is. How embarassing. As you correctly state it's *not* `ascender - descender' but the baseline-to-baseline distance. I'll undo the change (and add a comment). Sorry for the noise. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
