[ft-devel] goodbye and thank you
I'm now leaving the FreeType development mailing list. My product, CartoType, still relies on FreeType for its typography and will always do so, but I can no longer keep up with the discussions and new versions; I haven't got time, and I haven't contributed any changes or suggestions for a long while. I have been using FreeType since about 1998, when I was working for Symbian Ltd., and my claim to fame (well, not fame exactly, but a very small part of history) is that I introduced scalable vector fonts to two operating systems, Symbian and Blackberry OS, both sadly no longer with us, and used FreeType to achieve that. Thanks to David Turner and Werner Lemberg and everyone else for creating and improving FreeType over so many years. Best wishes, Graham -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world" - BUG FIX
I have found the bug causing the crash in my C version of the new floating-point rasterizer. It was possible for the accumulation array to be written using an illegal index of -1. The cause was that when the DrawLine code steps through the y values - the raster lines - it increments the x value by dxdy, which is (dx / dy). That float value will inevitably sometimes be imprecise, causing the x value to become just less than 1. For example, if a line is drawn from (0.484375,0.34375) to (0,0.771965563), dxdy ought to be -1.131147585..., but is rounded to the float value -1.13114762. In the first and only raster line, dy is 0.428215563, so x = 0.48375 and xnext (the next value of x) is x + dy * dxdy = -2.98023224e-08 - NOT zero, as it should be, but a small way below zero: so when the array index x01 is set to the next integer below nextx it becomes -1. Therefore the statement float x0floor = (float)floor(x0); becomes float x0floor = x0 <= 0.0f ? 0.0f : (float)floor(x0); with an explanatory comment. It goes without saying that changing from float to double would not fix the problem, only make it somewhat rarer. I have uploaded the new version to http://www.cartotype.com/assets/downloads/raster_fp/ . This was quite hard to debug because a write to the four bytes just before the start of a heap block does not cause an immediate crash. The crash happens when the block is deallocated. I added explicit array checking code, turned off optimisation in the release build of the CartoType demo (the debug build was too slow), ran it in the VS2015 debugger and caught the bug on about the thirty-one-millionth array access. Raph, you might like to check whether your Rust code has the same problem. I suspect that it does, because the lines (lines 69-70 in raster.rs) let x0floor = x0.floor(); let x0i = x0floor as i32; don't appear to prevent x0floor or x0i from being negative. - Graham On 19/08/2016 14:33, Graham Asher wrote: Right now I think the supposed bug doesn't exist, but was caused by forcibly closing a debug session in Visual Studio 2015. On 19/08/2016 14:02, Graham Asher wrote: I've fixed the clipping and winding rule bugs, and it now works well with CartoType map rendering, and seems fast although I have not benchmarked it against the older renderer. However, one note of caution: I think there is still a bug somewhere, probably a write beyond the end of an array; no doubt that is my fault. I will try to reproduce and fix it. I have uploaded the new version. On 19/08/2016 11:16, Graham Asher wrote: New version uploaded at http://www.cartotype.com/assets/downloads/raster_fp/ which is going to be its home for now. More news when I have done some more testing. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world" - new version available
Right now I think the supposed bug doesn't exist, but was caused by forcibly closing a debug session in Visual Studio 2015. On 19/08/2016 14:02, Graham Asher wrote: I've fixed the clipping and winding rule bugs, and it now works well with CartoType map rendering, and seems fast although I have not benchmarked it against the older renderer. However, one note of caution: I think there is still a bug somewhere, probably a write beyond the end of an array; no doubt that is my fault. I will try to reproduce and fix it. I have uploaded the new version. On 19/08/2016 11:16, Graham Asher wrote: New version uploaded at http://www.cartotype.com/assets/downloads/raster_fp/ which is going to be its home for now. More news when I have done some more testing. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world" - new version available
I've fixed the clipping and winding rule bugs, and it now works well with CartoType map rendering, and seems fast although I have not benchmarked it against the older renderer. However, one note of caution: I think there is still a bug somewhere, probably a write beyond the end of an array; no doubt that is my fault. I will try to reproduce and fix it. I have uploaded the new version. On 19/08/2016 11:16, Graham Asher wrote: New version uploaded at http://www.cartotype.com/assets/downloads/raster_fp/ which is going to be its home for now. More news when I have done some more testing. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world" - new version available
New version uploaded at http://www.cartotype.com/assets/downloads/raster_fp/ which is going to be its home for now. More news when I have done some more testing. On 19/08/2016 09:27, Graham Asher wrote: This isn't the final version; as always, after releasing a piece of code into the wild, one sees problems and omissions. Some notes: 1. My code does clipping, so that you can happily draw lines outside the raster. That isn't quite right yet - I need to make a simple change. 2. I am using a different winding rule from Raph. I will also fix that. Raph, can you comment on your winding-rule code? It takes the absolute value of the coverage then clamps it to 0...1 in your code; that seems to implement the non-zero winding rule. 3. It would be great to get Raph's comments on my cubic-spline code, built on the analogy of his quadratic code; and on the use of the magic constants 0.333 and 3.0 in determining the number of iterations when splitting a curve, and on the taking of a fourth root. 4. Raph's code uses 32-bit floating point numbers (float); it might be better to use 64-bit (double), because I believe that C always calculates to double-precision in any case, and so there is a conversion cost. I believe Raph uses float because floats are handled faster than doubles by hardware-accelerated SIMD code; but if not using SIMD, double may be better. There is also the raster working data size question. I use rasterization for large shapes in maps: a 1000 x 1000 pixel display needs 4Mb of working data in this system, with floats, and 8Mb with doubles. Not really a problem nowadays, but much larger than the typical FreeType rasterizer's render pool. I'll report back when I've tried it in CartoType. Note that my code runs fastest when formatted in Whitesmith's style ;-) Any attempt at reformatting will be stoutly resisted. - Graham On 19/08/2016 06:16, Werner LEMBERG wrote: I have successfully converted part of Raph Levien's code - that is, the floating-point rasterizer, not the TTF parser - into C, and it seems to work well, although I have run only a few small tests so far and have not yet benchmarked the speed. A big thank you, Graham! Very much appreciated. I don't know yet, however, when I will find some time to work on it. In case you want to do further integration into FreeType, please post your results here :-) One point that I may have to address is that there are declarations after statements, which seems to be OK in C nowadays, but wasn't formerly, I know; but that can be fixed trivially. OK. The code is attached. Naturally I have credited Raph and used the same license. There are documentation comments in the source. Regarding the license: Raph, would it be possible to add dual-licensing with GPL2 to the C code, or to change the C code to the two licenses that come with FreeType? Reason is that Apache 2.0 is not compatible with GPL2. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world" - conversion started
Behdad, It might be faster, but then again it might not be, depending on the value of n, the cost of the test for subdivision, and other things. I shall leave all of ftsmooth untouched; this will be an independent piece of software that may be connected to FreeType afterwards. However, I shall not be engaging in a general discussion about this, except for the odd question to Raph, but getting on with it, using my judgement as to how to proceed - committee programming is not for me. Anyone who wants to try other ways of converting what is a small piece of software can try their hand; as I said, there's no rocket science involved. - Graham On 12/08/2016 21:38, Behdad Esfahbod wrote: Because it's faster to subdivide into n segments in a single loop. But yeah, that doesn't really matter here, I think you can leave that part of ftsmooth untouched. On Aug 12, 2016 7:15 AM, "Graham Asher" <graham.as...@cartotype.com <mailto:graham.as...@cartotype.com>> wrote: Hi Werner, yes, I e-mailed him yesterday, and asked a question about his code too, but with no great hope of an early reply, knowing he's busy. I asked him why his code to handle quadratic splines used a division into a number of evenly spaced values for the t parameter rather than recursive Casteljau splitting. The question was triggered by seeing that there is a handler for quadratic splines but not for cubics in his code (it was written for TrueType only). I suspect the answer has to do with the use of floating-point rather than integer arithmetic, but if there is no good reason I will be tempted to (for now) use Casteljau splitting for cubic splines, or for both types. I am almost certain that it will have little impact on efficiency, or even improve it, but let's see. - Graham On 12/08/2016 06:45, Werner LEMBERG wrote: Hello Graham, I have started converting it to C++. I will do that for now because C would adds an extra layer of difficulty and slow the work down; but don't worry, there's no rocket science, and it should be easy to produce a C version when I've done it. great! Please inform Raph also (in case you haven't done so); I think he is not on this list. Wish me luck... I do :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org <mailto:Freetype-devel@nongnu.org> https://lists.nongnu.org/mailman/listinfo/freetype-devel <https://lists.nongnu.org/mailman/listinfo/freetype-devel> ___ Freetype-devel mailing list Freetype-devel@nongnu.org <mailto:Freetype-devel@nongnu.org> https://lists.nongnu.org/mailman/listinfo/freetype-devel <https://lists.nongnu.org/mailman/listinfo/freetype-devel> -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world" - conversion started
Hi Werner, yes, I e-mailed him yesterday, and asked a question about his code too, but with no great hope of an early reply, knowing he's busy. I asked him why his code to handle quadratic splines used a division into a number of evenly spaced values for the t parameter rather than recursive Casteljau splitting. The question was triggered by seeing that there is a handler for quadratic splines but not for cubics in his code (it was written for TrueType only). I suspect the answer has to do with the use of floating-point rather than integer arithmetic, but if there is no good reason I will be tempted to (for now) use Casteljau splitting for cubic splines, or for both types. I am almost certain that it will have little impact on efficiency, or even improve it, but let's see. - Graham On 12/08/2016 06:45, Werner LEMBERG wrote: Hello Graham, I have started converting it to C++. I will do that for now because C would adds an extra layer of difficulty and slow the work down; but don't worry, there's no rocket science, and it should be easy to produce a C version when I've done it. great! Please inform Raph also (in case you haven't done so); I think he is not on this list. Wish me luck... I do :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
I'd forgotten about that! I was the other person. On 05/08/2016 09:21, Ken Sharp wrote: Personally, as one of the two people who did a load of work to get FreeType integrated into Ghostscript -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
Werner, I see your point, but I think that adding obfuscation (the extra complexity introduced by using C) to the code to support a tiny and vanishing minority of systems without C++ is not worth the bother; such systems would very probably not be able to run FreeType in any case because of lack of support for 32-bit integers; and I doubt very much whether they would have any need to rasterize glyphs. There's an interesting discussion here (http://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems) which gives both sides of the issue, but which contains many errors and irrelevancies... however, I respect your point of view and won't tread a well-worn path again. Best regards, Graham On 05/08/2016 09:00, Werner LEMBERG wrote: I might take a look at it, but no guarantees about my availability. Thanks for the offer anyway :-) I would convert it into C++, not C; C++ is a better fit, and there is really no point in using C these days. I disagree. As far as I know, there are still embedded systems that don't have a C++ compiler (and probably never will). Given that everything in FreeType is C, it would be a severe complication if just a single file becomes C++. In other words, I would have to convert your C++ code in C, which means double work... As an alternative, there is https://github.com/uwplse/crust a Rust-to-C compiler – has anyone tried this? I don't know whether it produces code which runs as fast as the Rust equivalent. If this works reliably, I could imagine to have both a Rust source file and its translation in the FreeType git repository. Unfortunately, `crust' needs a huuuge set of preliminaries... Werner -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostics
Not this century. On 06/07/2016 10:37, Hin-Tak Leung wrote: Do people still care about restricting to the convention of 8.3 file names? -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostics
Please consider calling it ftdiagnostics.h, which is more explanatory.
To my native-English-speaking mind, 'diag' looks as if it stands for
'diagonal' or 'diagram'.
I think the enumeration values should be FT_DIAGNOSTIC_XXX too.
Sometimes it's a good idea to spell things out.
- Graham
On 06/07/2016 07:59, Werner LEMBERG wrote:
Here is the updated patch for 2.6.4 - there are some minor
collisions with the new subpixel hinting mode.
Attached is something that would fit better into FreeType
w.r.t. formatting, macro definitions, and function names. I suggest
to provide a public header file `ftdiag.h' that defines, similar to
`fterrdef.h', enumeration values `FT_DIAG_XXX' instead of the
currently used strings, together with proper declarations for
`TT_Diagnostics_{Unset,Set}' (which probably should use an `FT_'
prefix instead).
while updating the diff I looked into the global variable issue.
Putting the diagnostic messaging pointer inside TT_Face is fairly
straight forward, and it isn't too hard to do it per TT_Face, which
is even better than per FT_Library.
OK.
However
- diagnostics on parallel threads seem a bit of over-design - most
people are unlikely ever to test multiple faces in parallel.
Testing on single face is demanding enough - did I mention that it
took about 5 days of CPU time to run the MS 2003 binary through
the MS shipped fonts in win 8.1?
It's not about running the diagnostics in parallel but simply avoiding
global variables in general in case you want to have it integrated
into upstream FreeType. Right now, your changes are very small and
non-invasive, so I could easily add them.
- extracting the face handle and passing it back increases the
complexity of the C<->C# interface. Before implementing the
rasterization test, I have relied on SharpFont (
https://github.com/Robmaister/SharpFont ) to handle the C<->C#
interaction. And I have enhanced SharpFont on the way as needed.
The current change by-passes SharpFont. I do not want to spend
time increasing the complexity of what's really a temporary
by-pass.
Well, I can't comment on this.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] compile error with VS2013
It's a bold statement, based on a lot of commercial production experience with both IDEs, but not a hyperbolic one. Sure, FreeType can be built with VS2013, but why bother now VS2015 is out? VS2013 wasn't a very long-lived version. If an old version should be supported it would be better to maintain support for VS2008, which a lot of people used for five or six years. - Graham On 07/03/2016 13:00, John Tytgat wrote: On 3/7/2016 11:42 AM, Graham Asher wrote: I don' think it's necessary to support VS2013. It was buggy and incomplete compared to VS2015, which is much better. That's a pretty bold & hyperbolic statement. There is nothing intrinsically wrong with VS2013 Update 5 (or even earlier versions) to build FreeType. John. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] compile error with VS2013
I don' think it's necessary to support VS2013. It was buggy and incomplete compared to VS2015, which is much better. The community edition is free. Therefore I think it would be more productive to check whether the latest build works with VS2015, and fix any problems there first. - Graham On 07/03/2016 10:31, Werner LEMBERG wrote: There are errors when compiling FreeType 2.6.3 with Visual Studio 2013, But 2.6.2 is OK. Details, please. We need a log file or something similar. BTW, it would be best if you could try to compile the current git version of FreeType. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] typos in the documentation
On 06/12/2015 15:19, Nikolaus Waxweiler wrote: The autohinter has a new toggable stem darkening property A couple of typos: "The autohinter has a new toggable stem darkening property": The word 'toggable' doesn't exist. I think you mean 'toggleable' (although that is not the happiest of coinages). "to reduce those color-fringing": should be "to reduce those color fringes". Oh, I just noticed something else: "the capabilities of the used rendering system" should be "the capabilities of the rendering system"; the word 'used' is redundant and a 'used rendering system' is a second-hand one. If the entire text could be made available in a formatted and readable form, I would be happy to proof-read it for typos, grammar and correct English. Best regards, Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] enclosing FreeType in a C++ namespace
My product, CartoType, is sometimes supplied as a static C++ library,
and lately I've had some problems reported by users who also link to
other libraries containing conflicting versions of open-source
components, including FreeType, Zlib, Libpng, Libjpeg, Expat, etc.
One possible fix would be to take these components out of CartoType, and
allow users to link to their own versions, but that would compromise
consistency and maintainability. Therefore my solution has been to move
everything into the CartoType namespace; which means compiling the code
as C++ and enclosing all declarations and definitions in namespace
CartoType { ... }. Doing this has helped a number of my clients.
It may interest FreeType aficionados if I give a brief overview of how
to do this. My description is based on a somewhat older version of
FreeType, but I am sure it remains applicable.This is not the same as
creating a C++ wrapper for FreeType. It does not change the FreeType
API, but puts /everything/ into the C++ namespace, so that, for example
the full signature of FT_Init_FreeType becomes
CartoType::FT_Error CartoType::FT_Init_FreeType(CartoType::FT_Library*
alibrary)
Obviously any namespace would work here.
Here's the process I followed:
1. Rename all directly compiled .c files to .cpp. These are files that
are not #included, but are part of the main project. So ftbase.c,
ftinit.c, truetype.c, raster.c, etc., become ftbase.cpp, ftinit.cpp,
truetype.cpp, raster.cpp, etc. The renaming is not absolutely necessary
(you could just tell your compiler to compile everything as C++) but it
makes things a lot easier if you are working on five different
platforms, with many different project files and compilers; all the
compilers I use infer C or C++ from the file extension.
2. Change FT_LOCAL, etc, as follows:
#define FT_LOCAL( x ) x
#define FT_LOCAL_DEF( x ) x
#define FT_BASE( x ) x
#define FT_BASE_DEF( x ) x
#define FT_EXPORT( x ) x
#define FT_EXPORT_DEF( x ) x
#define FT_EXPORT_VAR( x ) extern x
#define FT_CALLBACK_DEF( x ) x
#define FT_CALLBACK_TABLE extern
#define FT_CALLBACK_TABLE_DEF extern
That is, various 'extern C' and 'static' qualifiers are removed.
3. Make FT_BEGIN_HEADER and FT_END_HEADER into the start and end of the
namespace:
#define FT_BEGIN_HEADER namespace CartoType {
#define FT_END_HEADER } // namespace CartoType
For this to work, I had to remove FT_BEGIN_HEADER and FT_END_HEADER from
pshalgo.h, because it #includes other headers; while 'extern C' can be
nested, a nested namespace is a different namespace.
4. Put all indirectly compiled .c files into the namespace. These are
the source files which were not renamed to .cpp files, and are #included
by them. They are compiled as C++ because they become part of the same
compilation unit when #included. For example, the file ttdriver.c
acquires 'namespace CartoType {' after all its #include statements, and
'} // namespace CartoType' at the end of the file. I had to do that to
about 40 files.
5. Fix up some annoyances in ftinit.cpp. The ordinary system for module
specification doesn't work, for reasons I am too bored to investigate
involving static object initialisation, 'extern' declarations and strict
type checking, so I have to declare the modules like this:
extern const FT_Module_Class psaux_module_class;
extern const FT_Module_Class psnames_module_class;
extern const FT_Module_Class pshinter_module_class;
extern const FT_Renderer_Class ft_raster1_renderer_class;
extern const FT_Module_Class sfnt_module_class;
extern const FT_Renderer_Class ft_smooth_renderer_class;
extern const FT_Driver_ClassRec tt_driver_class;
extern const FT_Driver_ClassRec t1_driver_class;
#define FT_USE_MODULE( x ) (const FT_Module_Class*)x,
const FT_Module_Class* const ft_default_modules[] =
{
#include FT_CONFIG_MODULES_H
0
};
6. There were some other small problems - pretty obvious stuff - but I
won't go into them because they have almost certainly been made obsolete
by changes to FreeType.
I have used the same technique for libpng, zlib, expat and libjpeg. (I
had some trouble with sqlite, so (for the moment) I have left it in C
and avoided namespace conflicts by a massive global renaming, adding a
prefix to all symbols.) Yes, I am aware that C and C++ are not entirely
compatible, but this has not caused any difficulties, apart from trivial
matters like casting the return value of malloc from void* to the
desired pointer type in a couple of places, and (in zlib) changing
old-style C function declarations to the current C and C++ syntax.
I hope all this is of interest.
Best regards,
Graham
--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] integer suffix abuse
I very much doubt this does any harm; modern compilers will do the right thing. It won't do any harm to get rid of the L suffixes, but it is unlikely to make any difference at all to compiled size or performance on any platforms that matter. Best regards, Graham On 24/06/2015 17:24, suzuki toshiya wrote: Hmm, therefore, should we remove all constants using L suffix directly, and use such constants as the macros which is defined with appropriate suffix under the cpp-conditionals for 16-bit, 32-bit and 64-bit systems? Regards, mpsuzuki Alexei Podtelezhnikov wrote: Hi All, I think we abuse the suffix L in integer constants. I understand the desire to make sure that very common 0x1L is 32-bit to represent a unit in 16.16 fixed-point representation. On modern 64-bit systems that actually becomes an unnecessary 64-bit constant. Perhaps the suffix was used with 16-bit systems in mind, but 0x1 cannot fit into 16-bit integer and will always be 32-bit even on 16-bit systems. Am I missing something? Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Query about freetype
Sai, you need to cache glyphs in some way; performance is not usually good enough to create glyphs on demand and throw them away. FreeType has a glyph caching system: http://www.freetype.org/freetype2/docs/reference/ft2-cache_subsystem.html. Best regards, Graham Asher On 17/10/2014 09:39, sai prashanthi wrote: Hello, I am running freetype on a new Graphics controller. Its quiet confidential. I am doing a basic text rendering. I am using the following functions i.e. Get_Char_Index Load_Glyph Get_Glyph Get_CBox Render Draw All the functions take a few microseconds to get executed except Load Glyph. It takes a few milli seconds. Is there something that I should take care of? Best regards, Sai Prashanthi Ramu On Tue, Oct 7, 2014 at 10:30 AM, Werner LEMBERG w...@gnu.org wrote: I am trying to port freetype to a graphicas controller (not out in the market yet). This might seem like a silly question. But I couldn't find sufficient documentation online. I am using freetype 1.0. I am allowed to use only this. Version 1.0 of FreeType? This has been released in 2000, 14 years ago! We no longer support FreeType 1. When I try TT_Open_Face, i should specify a path to font file. [...] Sorry. Please check the current FreeType version, 2.5.3. Due to its modular design you can easily disable all modules you don't need. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype support C++/CLI
Some time ago I built FreeType as managed code for .NET and used it in a project that used a C++/CLI wrapper, so it is definitely possible. I had to make some internal changes, though. FreeType used the identifier 'generic', which conflicts with a keyword in C++/CLI, s I replaced it with '_generic' throughout; and (from memory - it was some years ago), I think I had to replace all uses of setjmp and longjmp with the use of error codes propagated up the call stack. And the system then worked perfectly. I give this information merely to show that it's possible. I no longer have the code changes I made, and cannot give any support or further information. But knowing that something is possible can be encouraging. - Graham Asher On 16/05/2014 06:44, Werner LEMBERG wrote: I'll use freetype support C++/CLI as .net wrapper and in C# project reference it, but not depend on native dll. (I want to get a wrapper through the freetype, and build a dll, but this operation can't depend on the native dll) Sorry, I neither use .net nor C#, so I can't help. Any takers? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel -- Graham Asher founder and CTO CartoType Ltd graham.as...@cartotype.com +44 (0) 7718 895191 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Displaying a 'EURO' character in freetype.
Be sure to use the Unicode codepoint U+20A0, not the non-Unicode codepoint 0x80 used in Windows codepages. On 04/04/2014 14:48, suzuki toshiya wrote: Hi, If you see all glyphs in the font by ftview, could you find euro sign in your Arial? Regards, mpsuzuki On 04/04/2014 04:17 PM, Ashutosh Morwal wrote: Hello, I have been trying to display Euro '€' character using freetype, I can display UNICODE characters such as |âãäæë| , but I cannot display the Euro glyph. I am using Arial font to display other characters in windows and on mac, on windows i get some weird characters when I try to dislpay euro, but in mac, i do not see anything. Does FT support €? or am i using a wrong font file? Regards, Ashutosh. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Porting to C#/Mono
It may be of interest to know that some time ago I successfully got FreeType working as a pure .Net assembly - in other words, I compiled it as C++/CLI, which made it usable with general .Net applications. Of course, pure compilation is not necessary when using native-code assemblies, so this is probably of academic interest only, but may give some general guidance. There were just two problems, easily overcome; (i) the use of 'generic' as an identifier (e.g., in FT_FaceRec) - I changed them all to _generic to avoid conflicts with a C++/CLI keyword); and (ii) the use of setjmp/longjmp; I replaced these with the returning of error codes. What I was trying to do (unsuccessfully, as it turned out) was to create a pure .Net assembly for CartoType, my map rendering library, for use on platforms like Windows Phone 7 which don't allow native assemblies or indeed any native code. That was impossible because (I believe) I had not removed dependencies on native run-time libraries; and now the task has been rendered unnecessary by the release of Windows Phone 8, which supports native C or C++. Graham Asher CartoType Ltd. On 13/11/2012 08:12, Werner LEMBERG wrote: I 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] supporting coloured bitmaps in FreeType
*/
/* is an index to a palette of premultiplied ARGB color
values. */
/* The palette field of the FT_Bitmap structure points to
the */
/* base of the palette, which is an array of 4-byte
values. */
**
/* */*
typedef enum FT_Pixel_Mode_
{
FT_PIXEL_MODE_NONE = 0,
FT_PIXEL_MODE_MONO,
FT_PIXEL_MODE_GRAY,
FT_PIXEL_MODE_GRAY2,
FT_PIXEL_MODE_GRAY4,
FT_PIXEL_MODE_LCD,
FT_PIXEL_MODE_LCD_V,
*FT_PIXEL_MODE_ARGB_PRE,
FT_PIXEL_MODE_ARGB_PRE_PALETTE,
*FT_PIXEL_MODE_MAX /* do not remove */
} FT_Pixel_Mode;
Best regards,
Graham Asher
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] supporting coloured bitmaps in FreeType
Well, what I'm suggesting is just adding these constants, which is a 5 minute patch. I'm not allowed to release my client's bitmap font format (which I invented) into the wild. It would be nice to have a standard coloured-bitmap font format but it would probably not be a good idea for me to invent it for obvious reasons. On 15/08/2012 16:10, Werner LEMBERG wrote: 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] supporting coloured bitmaps in FreeType
I have asked my client whether they will consider allowing me to make their bitmap font format public-domain so that someone can write a clean FreeType driver for it. I have a driver for it but it's not 'clean': it depends on a huge amount of other proprietary stuff. We would also need a clean implementation of the tool to create the font from PNG images. It's unlikely that they will say yes, but if you don't ask, you don't get. Graham On 15/08/2012 16:10, Werner LEMBERG wrote: 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Amalgamation details
Vinnie, I support what you've done. It sounds very useful and as you say is not dangerous if used as intended. My choice in writing a cross-platform mapping library (CartoType) was to use a stable version of FreeType as an integral part of the CartoType library. I don't use any OS version of FreeType, or indeed any OS graphics primitives - to do so would invite trouble and inconsistency. By this means I get identical behaviour on all platforms. So it looks like I have the same constraints and aims as you. This way I keep my users happy and it's easier for me to maintain the code. Best regards, Graham Asher CartoType Ltd. On 14/04/2012 17:19, Vinnie wrote: From: Alan Coopersmithalan.coopersm...@oracle.com Do you know where most of the FreeType security issues in the past few years has been found? By people trying to hack smartphones via downloads of malicious PDF's or opening webpages with bad webfonts. That's only a vulnerability of the application in question allows loading of arbitrary fonts. For the case where an application simply wants hinted output of its own font used in a user interface, with the entire font file embedded in the application as static data or a resource (100% of my users) there is no issue! Of course, those smartphone OS'es are providing system font rendering using FreeType so you don't have to shove in another copy there. I agree and its on my to-do list to refine the amalgamation so that it detects and uses the system provided library on environments where it exists. This behavior will be overridable with a configuration macro, for those people who have built a rich GUI on top of a hinted font and did all their testing with a specific version of FreeType, and don't want to be exposed to a bug in a shared FreeType library making their application look bad (for example, a defect discovered in the auto hinter). The end-game is to build rich open source GUI components on top of the FreeType amalgamation which will seamlessly provide FreeType either through the amalgamated sources or the system provided libraries (at the programmer's option), with the ability to distribute these GUI components without external dependencies (by including the amalgamation in the source distribution). All this, with no Makefiles or platform specific configuration required. In other words, for dummies. Of course it is worth repeating once again this use-case is contemplated ONLY FOR FONTS EMBEDDED IN THE APPLICATION and not for fonts which come from external files! I know this is a difficult concept for a lot of people who have no experience writing shrink-wrapped applications (which seem to be going the way of the Dodo) so here is an example (again): http://m.artician.com/pu/3G665GVDE5WXL3A7SOS6MP4RCOI6MJHB.preview.jpeg This is GUI for an audio plugin. These plugins typically have compact interfaces with small text, which is a great candidate for hinting. A plugin author can choose a good hinted font, embed it in their application (using a command tool that converts a binary file into a giant C-style static array), and then use FreeType to draw the font and get nice output at the small sizes. The benefit of using a statically linked FreeType is that you can design your interface, test it against the specific FreeType version, and then be assured that no matter what the user has on their system in terms of FreeType libraries, the application or plugin appearance will not change. Most audio plugins are built on JUCE (http://rawmaterialsoftware/juce.php) which is specifically tuned for making it easy to write cross platform user interfaces and audio plugins in particular. For this reason, I have built a class that works with the JUCE font rendererer to provide hinted output for embedded fonts: http://vinniefalco.github.com/VFLib/class_free_type_faces.html I hope this rant has helped to provide a broadened view of the variety of ways in which FreeType may be used. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_Advance() docs
I know this isn't a welcome remark, but I'm going to say it anyway, because
it's a rule I apply to myself: if an API is difficult to explain then it should
be changed. Yes, I know you can't do that - but it's an argument for carefully
documenting something as it is written, and changing it before release if the
documentation gets too hard to write. And rather than saying a wording is
unfortunate, just change it.
An attempt at better wording for the quoted text:
You can set a flag that allows fast retrieval of advance values:
FT_ADVANCE_FLAG_FAST_ONLY. To use it, combine it with any other flags you're
passing to FT_Get_Advance or FT_Get_Advances. But it works only if the glyph is
unhinted (FT_LOAD_NO_HINTING), or unscaled (FT_LOAD_NO_SCALE), or bitmapped, or
if light hinting is used (FT_RENDER_MODE_LIGHT). If none of these conditions is
met, FT_Get_Advance or FT_Get_Advances will fail with
FT_Err_Unimplemented_Feature.
Graham
From: Werner LEMBERG w...@gnu.org
To: beh...@behdad.org
Cc: freetype-devel@nongnu.org
Sent: Wednesday, 30 November 2011, 14:30
Subject: Re: [ft-devel] FT_Get_Advance() docs
Testing suggests that [FT_Get_Advance] returns
glyph-linearHoriAdvance, not glyph-advance.x. This is
understandable, but unintuitive and not documented.
Hmm.
In fact, the following suggests that FT_Get_Advance() may in fact
take hinting into account:
This is correct.
But apparently it doesn't.
It does.
At any rate, would be nice to document what exactly is it that
FT_Get_Advance() returns, and what tests can the client use to
determine whether what FT_Get_Advance() returns matches
glyph-advance.x.
The behaviour depends on `load_flags' and on
FT_ADVANCE_FLAG_FAST_ONLY:
. If a glyph is unhinted (FT_LOAD_NO_HINTING), or unscaled
(FT_LOAD_NO_SCALE), or bitmapped, or if the light-hinted rendering
mode is active (FT_RENDER_MODE_LIGHT), quick retrieval of advance
widths is possible in general. However, you can only be sure
about that if you add FT_ADVANCE_FLAG_FAST_ONLY to `load_flags'
and assure that you don't get an error.
Depending on the load flags, you get either advance values in
FUnits (the sentence about `default' in the description of
FT_Get_Advance is rather unfortunate) or scaled values which are
then identical to the glyph-linear{Hori,Vert}Advance values.
. If the above conditions aren't met, FT_Load_Glyph is called, and
you get glyph-advance.{x,y} values.
I would be glad if you could suggest a better wording of the
documentation.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] regarding freetype 2 cubic curve flattening
Vivek, in fact the great work is David's, not mine - I made the original attempt, which was buggy, and then supplied a fix, but David wrote a new version which was justified mathematically and based on Hain's paper, as you mention. So I'll have to pass the responsibility for explaining it to David Bevan. Best regards, Graham On 30/10/2011 08:25, Vivek Rathod wrote: Hello Graham, I was looking at the new spline flattening algorithm that you and David worked on. The speed up due to this is fantastic. Great work! I could not understand the part of the code where you compare *s_limit* with *s *according to Hain's paper *dmax = (s/L) * dnorm ; *here s is not normalized. dmax is the tolerance for flatness and dnorm is the normalized flatness of the curve. so *s_limit* *= (dmax / dnorm) * L* ; by putting *dnorm* = 0.75 we get the permissible height of the control point for the curve not to be split. so should we not be comparing *s= abs(dy * dxi - dx * dyi)* with *s_limit * L *instead of *s* and *s_limit* ( because s is perpendicular distance of control point multiplied by L) ? Am I missing something very obvious? * *Thanks, Vivek Rathod ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2.4.6 has been released
All the 2.4.6 files on the savannah site give 404 errors :-( On 29/07/2011 05:52, Werner LEMBERG wrote: FreeType 2.4.6 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ The latter site also holds older versions of the FreeType library. See below for the relevant snippet from the CHANGES file; users of version 2.4.5 should upgrade immediately. Enjoy! Werner -- 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.5 and 2.4.6 I. IMPORTANT BUG FIXES - For TrueType based fonts, the ascender and descender values were incorrect sometimes (off by a pixel if the ppem value was not a multiple of 5). Depending on the use you might now experience a different layout; the change should result in better, more consistent line spacing. - Fix CVE-2011-0226 which causes a vulnerability while handling Type 1 fonts. - BDF fonts containing glyphs with negative values for ENCODING were incorrectly rejected. This bug has been introduced in FreeType version 2.2.0. - David Bevan contributed a major revision of the FreeType stroker code: . The behaviour of FT_STROKER_LINEJOIN_BEVEL has been corrected. . A new line join style, FT_STROKER_LINEJOIN_MITER_FIXED, has been introduced to support PostScript and PDF miter joins. . FT_STROKER_LINEJOIN_MITER_VARIABLE has been introduced as an alias for FT_STROKER_LINEJOIN_MITER. . Various stroking glitches has been fixed. II. MISCELLANEOUS - SFNT bitmap fonts which contain an outline glyph for `.notdef' only no longer set the FT_FACE_FLAG_SCALABLE flag. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2.4.6 has been released
Thank you. I know. I was reporting an error on the savannah site, which ought to work as advertised. On 29/07/2011 09:40, İsmail Dönmez wrote: Use sourceforge. It works. On Fri, Jul 29, 2011 at 10:38 AM, Graham Asher graham.as...@cartotype.com mailto:graham.as...@cartotype.com wrote: All the 2.4.6 files on the savannah site give 404 errors :-( On 29/07/2011 05:52, Werner LEMBERG wrote: FreeType 2.4.6 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ The latter site also holds older versions of the FreeType library. See below for the relevant snippet from the CHANGES file; users of version 2.4.5 should upgrade immediately. Enjoy! Werner -- 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.5 and 2.4.6 I. IMPORTANT BUG FIXES - For TrueType based fonts, the ascender and descender values were incorrect sometimes (off by a pixel if the ppem value was not a multiple of 5). Depending on the use you might now experience a different layout; the change should result in better, more consistent line spacing. - Fix CVE-2011-0226 which causes a vulnerability while handling Type 1 fonts. - BDF fonts containing glyphs with negative values for ENCODING were incorrectly rejected. This bug has been introduced in FreeType version 2.2.0. - David Bevan contributed a major revision of the FreeType stroker code: . The behaviour of FT_STROKER_LINEJOIN_BEVEL has been corrected. . A new line join style, FT_STROKER_LINEJOIN_MITER_FIXED, has been introduced to support PostScript and PDF miter joins. . FT_STROKER_LINEJOIN_MITER_VARIABLE has been introduced as an alias for FT_STROKER_LINEJOIN_MITER. . Various stroking glitches has been fixed. II. MISCELLANEOUS - SFNT bitmap fonts which contain an outline glyph for `.notdef' only no longer set the FT_FACE_FLAG_SCALABLE flag. ___ Freetype-devel mailing list Freetype-devel@nongnu.org mailto:Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org mailto:Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] stroker - bevel joins
David, here's a quote concerning optimisation from an e-mail of mine to Werner back in March when I was looking into this - key quote in bold below: I have also discovered that CartoType's method of stroking paths is much faster than FreeType's (more than twice as fast, I think - at any rate, it makes CartoType benchmark at about 10 seconds as opposed to 15 seconds, and CartoType does a lot of other things; this was disappointing to me because I had hoped to speed up CartoType by using the FreeType method). I don't have time to create a FreeType version of the CartoType system right now, but I think it's because *CartoType uses the intersections of parallels to get inner join positions, while FreeType calculates them using trigonometry.* I'm happy to share CartoType's system with the world if it's of interest - but again, it's a matter of time, because I am very busy and CartoType's C++ coding style is very different from FreeType's C, so I'd have to do a lot of conversion. Credit for CartoType's system is due to my colleague Lex Warners (now inactive, alas), who also implemented the fixed-point trigonometric routines. I haven't had time to think about the mitre limit yet. Best regards, Graham On 28/06/2011 09:01, David Bevan wrote: Graham, Thanks for the feedback. I'm glad you're using it. At least there's someone who will be able to review / test my changes. I'll look into the issue you mention. Perhaps you could forward me your ideas for increasing performance, since I'm working on the code at the moment. Do you have any view on handling the miter limit? I will implement option 4 below unless I receive feedback in favour of a different approach. Thanks. David %^ From: Graham Asher [mailto:graham.as...@cartotype.com] Sent: 27 June 2011 17:14 To: David Bevan Cc: Werner LEMBERG; freetype-devel@nongnu.org Subject: Re: [ft-devel] stroker - bevel joins I use the stroker - not in anger, but sometimes in sorrow ;-) Actually it seems quite good, but it could do with some speed optimisation, which I have discussed before with Werner; I made some concrete suggestions based on a comparison with CartoType's stroker, which is somewhat faster. I also discovered that - for my purposes, which may be different from other people's, but I think this is a general bug - the direction of the outer and inner borders is swapped for envelopes of closed strokes, thus: ft_stroke_border_close( stroker-borders + 0, TRUE ); ft_stroke_border_close( stroker-borders + 1, FALSE ); should be ft_stroke_border_close( stroker-borders + 0, FALSE ); ft_stroke_border_close( stroker-borders + 1, TRUE ); The effect of the bug is to produce voids when filling envelopes of closed strokes that overlap other closed paths, because the outer border is clockwise and the inner is anti-clockwise; for correct filling, the outer should be anti-clockwise and the inner clockwise. That's based on a slightly out-of-date version, so forgive me if it's been fixed. Graham Asher CartoType Ltd On 27/06/2011 16:05, David Bevan wrote: Hi! While developing code to support stroked text, we encountered a number of significant issues with the FT stroker. I will be submitting various fixes later in the week. However, one of the issues requires discussion (or at least agreement) beforehand. The PostScript/PDF References specify that the form of a bevel join (whether specified explicitly, or created as a result of exceeding the miter limit) is not dependent on the value of the miter limit. See the attached miter.pdf for an example. The current FreeType code generates the bevel join using a different algorithm that does depend on the miter limit. This actually accords with the way the miter limit is handled in XPS (see attached extract from the spec). NB: Be aware, if you look at the current code, that a miter join is called a bevel join and vice versa (and hence explicit bevel joins are implemented incorrectly). This will be fixed. What do we want to do? 1. Change the implementation to match the PS/PDF References, discarding the XPS-style approach. 2. Support both, with FT_STROKER_LINEJOIN_MITER matching the PS/PDF References, and a new FT_STROKER_LINEJOIN_VARIABLE_MITER for the XPS-style approach. 3. Support both, with FT_STROKER_LINEJOIN_MITER unchanged, and a new FT_STROKER_LINEJOIN_FIXED_MITER for the PS/PDF approach. 4. Support both, with FT_STROKER_LINEJOIN_FIXED_MITER and FT_STROKER_LINEJOIN_VARIABLE_MITER, and FT_STROKER_LINEJOIN_MITER an alias for FT_STROKER_LINEJOIN_VARIABLE_MITER (the existing behaviour). Something else. 1 2 introduce a backwards incompatibility, but is anyone actually using the stroker in anger? As long as FT supports the PS/PDF approach, any of these is acceptable for us. What do others think? Thanks. David %^ David Bevan Development Manager Pitney Bowes Emtex
Re: [ft-devel] stroker - bevel joins
I use the stroker - not in anger, but sometimes in sorrow ;-) Actually it seems quite good, but it could do with some speed optimisation, which I have discussed before with Werner; I made some concrete suggestions based on a comparison with CartoType's stroker, which is somewhat faster. I also discovered that - for my purposes, which may be different from other people's, but I think this is a general bug - the direction of the outer and inner borders is swapped for envelopes of closed strokes, thus: | ft_stroke_border_close( stroker-borders + 0, TRUE ); ft_stroke_border_close( stroker-borders + 1, FALSE ); | should be | ft_stroke_border_close( stroker-borders + 0, FALSE ); ft_stroke_border_close( stroker-borders + 1, TRUE ); | The effect of the bug is to produce voids when filling envelopes of closed strokes that overlap other closed paths, because the outer border is clockwise and the inner is anti-clockwise; for correct filling, the outer should be anti-clockwise and the inner clockwise. That's based on a slightly out-of-date version, so forgive me if it's been fixed. Graham Asher CartoType Ltd On 27/06/2011 16:05, David Bevan wrote: Hi! While developing code to support stroked text, we encountered a number of significant issues with the FT stroker. I will be submitting various fixes later in the week. However, one of the issues requires discussion (or at least agreement) beforehand. The PostScript/PDF References specify that the form of a bevel join (whether specified explicitly, or created as a result of exceeding the miter limit) is /not/ dependent on the value of the miter limit. See the attached miter.pdf for an example. The current FreeType code generates the bevel join using a different algorithm that /does/ depend on the miter limit. This actually accords with the way the miter limit is handled in /XPS/ (see attached extract from the spec). NB: Be aware, if you look at the current code, that a miter join is called a bevel join and /vice versa/ (and hence explicit bevel joins are implemented incorrectly). This will be fixed. What do we want to do? 1.Change the implementation to match the PS/PDF References, discarding the XPS-style approach. 2.Support both, with FT_STROKER_LINEJOIN_MITER matching the PS/PDF References, and a new FT_STROKER_LINEJOIN_VARIABLE_MITER for the XPS-style approach. 3.Support both, with FT_STROKER_LINEJOIN_MITER unchanged, and a new FT_STROKER_LINEJOIN_FIXED_MITER for the PS/PDF approach. 4.Support both, with FT_STROKER_LINEJOIN_FIXED_MITER and FT_STROKER_LINEJOIN_VARIABLE_MITER, and FT_STROKER_LINEJOIN_MITER an alias for FT_STROKER_LINEJOIN_VARIABLE_MITER (the existing behaviour). 5.Something else. 1 2 introduce a backwards incompatibility, but is anyone actually using the stroker in anger? As long as FT supports the PS/PDF approach, any of these is acceptable for us. What do others think? Thanks. David %^ David Bevan Development Manager Pitney Bowes Emtex Software Tel: +44 (0)1923 279300 david.be...@pb.com mailto:david.be...@pb.com ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_StrokerRec::valid is not used
I have discovered some other minor optimisations to the stroker module, but I'm not sure if it's worth mentioning them - they won't provide much speed improvement but will get rid of some anomalies and inefficiencies. I've been experimenting with a modified version of the stroker in CartoType, in the expectation that FreeType's system is faster than my own home-grown one (I don't know the answer to that yet). Map renderers make very heavy use of strokers for road envelopes, and envelopes of other linear features, and polygon borders. Best regards, Graham On 16/03/2011 07:55, Werner LEMBERG wrote: The data member FT_StrokerRec::valid does not seem to be used. I therefore recommend that it is removed. Done, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_StrokerRec::valid is not used
The data member FT_StrokerRec::valid does not seem to be used. I therefore recommend that it is removed. Best regards, Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2 for OSX
There are absolutely no difficulties in compiling FreeType using Xcode. We do that for iOS and MacOS versions of CartoType. The easiest way is to compile it in as part of the program you are writing: just add the FreeType sources to the project and make sure the include file path is right (as Werner said). Graham Asher CartoType Ltd. - Original Message From: Werner LEMBERG w...@gnu.org To: jkl...@leadwerks.com Cc: freetype-devel@nongnu.org Sent: Monday, 20 December, 2010 9:33:31 Subject: Re: [ft-devel] FreeType 2 for OSX Where can I find complete documentation on how to include the FreeType 2 library in an Xcode project? You are on the wrong list with this question since FreeType is not specific to Xcode, sorry. The general outline should be generic; there is nothing special in installing using FreeType: . add the path to the FreeType headers to the list of include files (if not installed at the default place) . add the path to the FreeType library to the list of library directories (if not installed at the default place) . add FreeType to the list of libraries to link with Note that I've never used or even seen Xcode... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
Aleksei, you really shouldn't be annoyed. My earlier patch was shown to be inferior to David Bevan's, and I was obliged to accept the fact. The only possible criteria are objective ones: does it work? is it faster? is it simpler? I believe David has shown using objective arguments that the patch should not be included. That's not a run-around. It is a courteous consideration of your suggestion, and you should be grateful for it. Also, you don't help your case at all by remarks like I think I can get though to this guy... and It's only you and me who understand these conditions. which are at best patronising and at worst impolite. Best regards, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Friday, 12 November, 2010 12:16:14 Subject: Re: [ft-devel] cubic clean up I am really annoyed by run-arounds and overzealous protection of code by authors. I was proposing a minor benign improvement. I am touching the water so to speak. What's the big deal? Way to attract developers, freetypers! You go! ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
There is no gain or loss in speed and the quality is the same In that case the patch should not be applied. Any change but the very simplest has some risk. Risk should only be undergone if there is demonstrable benefit. Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Tuesday, 9 November, 2010 0:50:48 Subject: [ft-devel] cubic clean up Hi, This patch should not be controversial. It simplifies the code. 1) It replaces 2 comparisons in FT_MAX and FT_MIN with a single one. 2) It implements a simpler and better check for closeness of control points to the chord There is no gain or loss in speed and the quality is the same (see images). More on 2). Currently the control points are required to be between the parallel lines through the chord ends. The proposed check requires that they are inside a circle. Given an earlier check for the perpendicular distance to the chord, these are actually almost equivalent. So the whole patch is just a clean up. Thanks, Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd
Please give evidence of ugliness in the form of images, preferable in sets of three: (i) before the patch from David Bevan and myself; (ii) using the current version of FreeType; (iii) using your suggested patch. Thanks, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: Werner LEMBERG w...@gnu.org Cc: freetype-devel@nongnu.org Sent: Wednesday, 20 October, 2010 13:19:52 Subject: [ft-devel] Re: FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd Werner, Graham, Please do not let this slip through the cracks. If you do not want to harmonize conic and cubic splines completely, you have two choices: 1) DOWNSCALE(ONE_PIXEL) in the conic splines 2) move UPSCALE coordinates to the top of the conic function The former is ugly in my opinion. The latter at least harmonizes how the conic and cubic splines work from the start. Also, you may consider moving back to ONE_PIXEL / 4 in the conics, as Graham originally intended, but may need some rendering quality control. As it stands right now the truetypes are dog-ugly. Alexei 2010/10/17 Алексей Подтележников apodt...@gmail.com: On Sun, Oct 17, 2010 at 4:53 AM, Werner LEMBERG w...@gnu.org wrote: It turns out that since 2.4.3 the cubic deviations have been estimated *after* UPSCALE, whereas conic ones have been evaluated *before* UPSCALE. This was probably the original sin that led to the misuse of FT_MAX_CURVE_DEVIATION that we've just fixed in cubic. Let's fix the original sin now. I won't comment the patch itself since I'm not too acquainted with those intricate geometric details. However, please resend your patch as an attachment; your mailing program inserts replaces ordinary spaces with non-breaking space characters at arbitrary places... Ok. I'm resending the non-intrusive patch as an attachment. The intrusive harmonization of the conic and cubic splines is to follow in a separate thread. Alexei -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] harmonize conic and cubic splines
I am sorry to say that I regard a 3% slowdown as intolerable, especially for my purposes. I haven't noticed any quality problems with the existing code. We can define quality as the inverse of the maximum distance of the generated line segments from the actual curve; that can be adjusted using the existing algorithm, in any case. The aim of code improvement in this area is to improve speed while preserving quality. Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Monday, 18 October, 2010 4:37:52 Subject: [ft-devel] harmonize conic and cubic splines Werner, This patch harmonizes the algorithms that are used for flattening conic and cubic splines. It changes the conic ones to follow the same (more correct) procedure as cubic ones. The result, I think, is a better code and a slight improvement in quality. You may see about 3% slow-down, but this can be ironed out. Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Alexei, I don't have much time or energy for this at the moment - sorry. Of course I will be looking at it again, but I believe that the solution hammered out by David Bevan and myself is a good one - it solves the bug I introduced while retaining the speed increases I first made the changes for. Please note that the definition of FT_MAX_CURVE_DEVIATION as 16 gives a value of 1/4, not 1/16 as you suggest. This code works in units of 1/64 of a pixel. Best regards, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Wednesday, 13 October, 2010 2:25:40 Subject: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL Guys, Currently smooth/ftgrays.c contains this: /* The maximum distance of a curve from the chord, in 64ths of a pixel; */ /* used when flattening curves. */ #define FT_MAX_CURVE_DEVIATION 16 and this: /* must be at least 6 bits! */ #define PIXEL_BITS 8 #define ONE_PIXEL ( 1L PIXEL_BITS ) Wouldn't that make sense to reconcile the two and possibly just use an explicit fraction of ONE_PIXEL instead? If I am not confused FT_MAX_CURVE_DEVIATION could be replaced with a larger value. 16 / 256th is really very conservative and you still make too many splits. Also, s and s_limit actually mean some sort of an area measure. It would make perfect sense to use TArea as type of these variables. Finally, I have more geometrical suggestions, but I'll wait with the patch, until I hear back Re this and my previous message. Best, Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
I guess my version has PIXEL_BITS = 6. Sorry, didn't notice the discrepancy. Yes, FT_MAX_CURVE_DEVIATIO ought to be defined so that it's always 1/4 of a pixel. Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: GRAHAM ASHER graham.as...@btinternet.com Cc: freetype-devel freetype-devel@nongnu.org Sent: Wednesday, 13 October, 2010 13:14:42 Subject: Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL Please confirm that ONE_PIXEL defined as 256 is not the unit of one pixel. What is ONE_PIXEL then? 2010/10/13 GRAHAM ASHER graham.as...@btinternet.com: Alexei, I don't have much time or energy for this at the moment - sorry. Of course I will be looking at it again, but I believe that the solution hammered out by David Bevan and myself is a good one - it solves the bug I introduced while retaining the speed increases I first made the changes for. Please note that the definition of FT_MAX_CURVE_DEVIATION as 16 gives a value of 1/4, not 1/16 as you suggest. This code works in units of 1/64 of a pixel. Best regards, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Wednesday, 13 October, 2010 2:25:40 Subject: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL Guys, Currently smooth/ftgrays.c contains this: /* The maximum distance of a curve from the chord, in 64ths of a pixel; */ /* used when flattening curves. */ #define FT_MAX_CURVE_DEVIATION 16 and this: /* must be at least 6 bits! */ #define PIXEL_BITS 8 #define ONE_PIXEL ( 1L PIXEL_BITS ) Wouldn't that make sense to reconcile the two and possibly just use an explicit fraction of ONE_PIXEL instead? If I am not confused FT_MAX_CURVE_DEVIATION could be replaced with a larger value. 16 / 256th is really very conservative and you still make too many splits. Also, s and s_limit actually mean some sort of an area measure. It would make perfect sense to use TArea as type of these variables. Finally, I have more geometrical suggestions, but I'll wait with the patch, until I hear back Re this and my previous message. Best, Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] on the subject of better splines
Alexi, I think it's a good idea if you can benchmark the code to see if the extra arithmetic results in any speed improvement. I suspect it might slow things down slightly for ordinary glyphs which always fit in a single band, but there's a chance it might help at high resolutions where more than one band is needed. Also, at first glance your code looks as if it might be subject to integer overflow or division by zero. The patch that's just been checked in result from work by David Bevan and myself does in fact make some improvements to gray_render_conic, though it doesn't address the point you are making. Best regards, Graham On 02/10/2010 03:57, Алексей Подтележников wrote: Hello, While you guys are on the subject of better splines. I propose to fix grey_render_conic too. I think that interpreting the control point as a corner is a simplistic overestimation. A little algebra gives the exact boundary position. Nothing breaks at the firsts glance in my testing. Whether this speeds things up, I do not know how to measure. Lastly. the equation below assumes that conic really means quadratic, in agreement with the logic of grey_split_conic. Comments? Alexi --- a/src/smooth/ftgrays.c 2010-07-12 15:09:25.0 -0400 +++ b/src/smooth/ftgrays.c 2010-10-01 21:58:05.182637518 -0400 @@ -936,16 +936,18 @@ TPos min, max, y; +/* set the boundaries based on the endpoints */ min = max = arc[0].y; -y = arc[1].y; -if ( y min ) min = y; -if ( y max ) max = y; - y = arc[2].y; if ( y min ) min = y; if ( y max ) max = y; +/* amend the boundaries based on the control point */ +y = arc[1].y; +if ( y min ) min = (min * max - y * y) / (min + max - 2 * y); +if ( y max ) max = (min * max - y * y) / (min + max - 2 * y); + if ( TRUNC( min )= ras.max_ey || TRUNC( max ) ras.min_ey ) goto Draw; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] version 3 of the spline flattening patch
Here is a third and I hope final version of the spline flattening
patch, incorporating the latest version of David Bevan's cubic spline
flattening routine.
Notes:
1. As with the previous versions, it solves the bug in flattening
s-shaped curves (cubic with control points on both sides of the chord).
2. I have incorporated David's latest code as is. However, I have
expanded his comments, most importantly (i) by giving the reference to
Hain's paper in full rather than as a tinyurl, so as to make it easier
to find elsewhere if it is moved or if the tinyurl service is
discontinued, and (ii) by incorporating a detailed explanation he
provided of the calculation of L.
3. It may be thought advisable to split the patch into two: one for
cubics, which is essential because it fixes a bug, and one for conics,
which is not essential but gives some speed improvement and simpler
code. I leave that up to Werner.
Graham
diff --git a/C:\\DOCUME~1\\Graham\\LOCALS~1\\Temp\\ftgrays_c8f5b9.c
b/C:\\DOCUME~1\\Graham\\LOCALS~1\\Temp\\ftgrays_f4f03b.c
index 0b94143..a3a7a31 100644
--- a/C:\\DOCUME~1\\Graham\\LOCALS~1\\Temp\\ftgrays_c8f5b9.c
+++ b/C:\\DOCUME~1\\Graham\\LOCALS~1\\Temp\\ftgrays_f4f03b.c
@@ -90,6 +90,9 @@
#undef FT_COMPONENT
#define FT_COMPONENT trace_smooth
+/* The maximum distance of a curve from the chord, in 64ths of a pixel; */
+/* used when flattening curves. */
+#define FT_MAX_CURVE_DEVIATION 16
#ifdef _STANDALONE_
@@ -354,8 +357,6 @@ typedef ptrdiff_t FT_PtrDist;
int band_size;
int band_shoot;
-int conic_level;
-int cubic_level;
ft_jmp_buf jump_buffer;
@@ -888,31 +889,18 @@ typedef ptrdiff_t FT_PtrDist;
if ( dx dy )
dx = dy;
-level = 1;
-dx = dx / ras.conic_level;
-while ( dx 0 )
+if ( dx = FT_MAX_CURVE_DEVIATION )
{
- dx = 2;
- level++;
+ gray_render_line( RAS_VAR_ UPSCALE( to-x ), UPSCALE( to-y ) );
+ return;
}
-/* a shortcut to speed things up */
-if ( level = 1 )
+level = 1;
+dx /= FT_MAX_CURVE_DEVIATION;
+while ( dx 1 )
{
- /* we compute the mid-point directly in order to avoid */
- /* calling gray_split_conic() */
- TPos to_x, to_y, mid_x, mid_y;
-
-
- to_x = UPSCALE( to-x );
- to_y = UPSCALE( to-y );
- mid_x = ( ras.x + to_x + 2 * UPSCALE( control-x ) ) / 4;
- mid_y = ( ras.y + to_y + 2 * UPSCALE( control-y ) ) / 4;
-
- gray_render_line( RAS_VAR_ mid_x, mid_y );
- gray_render_line( RAS_VAR_ to_x, to_y );
-
- return;
+ dx = 2;
+ level++;
}
arc = ras.bez_stack;
@@ -957,21 +945,9 @@ typedef ptrdiff_t FT_PtrDist;
}
Draw:
- {
-TPos to_x, to_y, mid_x, mid_y;
-
-
-to_x = arc[0].x;
-to_y = arc[0].y;
-mid_x = ( ras.x + to_x + 2 * arc[1].x ) / 4;
-mid_y = ( ras.y + to_y + 2 * arc[1].y ) / 4;
-
-gray_render_line( RAS_VAR_ mid_x, mid_y );
-gray_render_line( RAS_VAR_ to_x, to_y );
-
-top--;
-arc -= 2;
- }
+ gray_render_line( RAS_VAR_ arc[0].x, arc[0].y );
+ top--;
+ arc -= 2;
}
return;
@@ -1011,55 +987,8 @@ typedef ptrdiff_t FT_PtrDist;
const FT_Vector* control2,
const FT_Vector* to )
{
-int top, level;
-int*levels;
FT_Vector* arc;
-int mid_x = ( DOWNSCALE( ras.x ) + to-x +
- 3 * (control1-x + control2-x ) ) / 8;
-int mid_y = ( DOWNSCALE( ras.y ) + to-y +
- 3 * (control1-y + control2-y ) ) / 8;
-TPosdx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
-TPosdy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
-
-if ( dx 0 )
- dx = -dx;
-if ( dy 0 )
- dy = -dy;
-if ( dx dy )
- dx = dy;
-
-level = 1;
-dx /= ras.cubic_level;
-while ( dx 0 )
-{
- dx = 2;
- level++;
-}
-
-if ( level = 1 )
-{
- TPos to_x, to_y;
-
-
- to_x = UPSCALE( to-x );
- to_y = UPSCALE( to-y );
-
- /* Recalculation of midpoint is needed only if */
- /* UPSCALE and DOWNSCALE have any effect. */
-
-#if ( PIXEL_BITS != 6 )
- mid_x = ( ras.x + to_x +
-3 * UPSCALE( control1-x + control2-x ) ) / 8;
- mid_y = ( ras.y + to_y +
-3 * UPSCALE( control1-y + control2-y ) ) / 8;
-#endif
-
- gray_render_line( RAS_VAR_ mid_x, mid_y );
- gray_render_line( RAS_VAR_ to_x, to_y );
-
- return;
-}
arc = ras.bez_stack;
arc[0].x = UPSCALE( to-x );
@@ -1071,60 +1000,98 @@ typedef ptrdiff_t FT_PtrDist;
arc[3].x = ras.x;
arc[3].y = ras.y;
-levels= ras.lev_stack;
-top = 0;
-levels[0] = level;
-
-while ( top = 0 )
+for (;;)
{
- level = levels[top];
- if ( level 1 )
- {
-
Re: [ft-devel] Re: [ft] Question about FreeType usage
Symbian and RIM OS also use FreeType for rendering fonts on displays. I know because I put it there :-) Graham - Original Message From: Werner LEMBERG w...@gnu.org To: djko...@aol.com Cc: freetype-annou...@nongnu.org; freet...@nongnu.org; freetype-devel@nongnu.org Sent: Tuesday, 14 September, 2010 15:07:30 Subject: [ft-devel] Re: [ft] Question about FreeType usage I would like to know if FreeType is used in any consumer or enterprise printers either currently or in the past? Yes, it is. This is what we've heard. If it is possible can you divulge which printer manufactures and models have FreeType as their main font renderer. I don't know any. Also for interest what current OS's use FreeType for rendering fonts on displays. Virtually all OSes which use X11. iPhone and Android use it too. If manufactures use FreeType in their products how do you want the credits for your work to be announced? This is described in the FreeType License, FTL.TXT. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] latest patch file for spline flattening
David,
I've tested your code with CartoType, my map rendering library, and it
produces a small speedup there too. (The smallness of the speedup is to
do with the fact that CartoType's curves are nearly always
approximations to arcs of circles, which don't behave too badly with my
previous optimisation; I can see why your code works better with font
glyphs.)
Therefore, combined with the fact that it significantly speeds up font
rendering, and solves the bug that prompted this latest burst of work, I
recommend that it goes into FreeType.
Werner, can you give a ruling on whether assignments in conditionals are
allowed in FreeType code?
David, what value are you using for FT_MAX_CURVE_DEVIATION? I assume 16,
which is a good conservative value.
The full patch also requires getting rid of the now-unneeded cubic-level
and conic-level variables, and making minor changes to the conic
splitting routine. However, we could perhaps make the change to cubic
splitting independent of any changes to conic splitting, because the
latter doesn't suffer from the original bug ('if it ain't broke don't
fix it').
Best regards,
Graham
On 08/09/2010 08:50, David Bevan wrote:
Graham,
Here's a final revision.
It produces exactly the same results as the previous one but the code is a bit
faster (and also easier to understand - the previous code was trying to be a
bit too clever).
David %^
static void
gray_render_cubic( RAS_ARG_ const FT_Vector* control1,
const FT_Vector* control2,
const FT_Vector* to )
{
FT_Vector* arc;
arc = ras.bez_stack;
arc[0].x = UPSCALE( to-x );
arc[0].y = UPSCALE( to-y );
arc[1].x = UPSCALE( control2-x );
arc[1].y = UPSCALE( control2-y );
arc[2].x = UPSCALE( control1-x );
arc[2].y = UPSCALE( control1-y );
arc[3].x = ras.x;
arc[3].y = ras.y;
for (;;)
{
/* Check that the arc crosses the current band. */
TPos min, max, y;
min = max = arc[0].y;
y = arc[1].y;
if ( y min ) min = y;
if ( y max ) max = y;
y = arc[2].y;
if ( y min ) min = y;
if ( y max ) max = y;
y = arc[3].y;
if ( y min ) min = y;
if ( y max ) max = y;
if ( TRUNC( min )= ras.max_ey || TRUNC( max ) 0 )
goto Draw;
/* Decide whether to split or draw */
/* See Hain's paper at http://tinyurl.com/HainBez for more info */
{
TPos dx, dy, L, dx1, dy1, dx2, dy2, s, s_limit;
/* dx and dy are x- and y- components of the P0-P3 chord vector */
dx = arc[3].x - arc[0].x;
dy = arc[3].y - arc[0].y;
/* L is an (under)estimate of the Euclidean distance P0-P3 */
L = ( 236 * FT_MAX(labs(dx), labs(dy))
+ 97 * FT_MIN(labs(dx), labs(dy))) 8;
/* avoid possible arithmetic overflow below by splitting */
if (L 32767)
goto Split;
/* s is L * the perpendicular distance from P1 to the line P0-P3 */
s = labs( dy * (dx1 = arc[1].x - arc[0].x)
- dx * (dy1 = arc[1].y - arc[0].y));
/* max deviation may be as much as (s/L) * 3/4 (if Hain's v = 1) */
if (s (s_limit = L * (TPos)(FT_MAX_CURVE_DEVIATION / 0.75)))
goto Split;
/* s is L * the perpendicular distance from P2 to the line P0-P3 */
s = labs( dy * (dx2 = arc[2].x - arc[0].x)
- dx * (dy2 = arc[2].y - arc[0].y));
/* max deviation may be as much as (s/L) * 3/4 (if Hain's v = 1) */
if (s s_limit)
goto Split;
/* if P1 or P2 is outside P0-P3, split */
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
)
goto Split;
/* no reason to split */
goto Draw;
}
Split:
gray_split_cubic( arc );
arc += 3;
continue;
Draw:
gray_render_line( RAS_VAR_ arc[0].x, arc[0].y );
if (arc == ras.bez_stack)
return;
arc -= 3;
}
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] latest patch file for spline flattening
No, forget that, I was getting confused. Graham On 12/09/2010 11:16, Graham Asher wrote: On 08/09/2010 08:50, David Bevan wrote: if (s (s_limit = L * (TPos)(FT_MAX_CURVE_DEVIATION / 0.75))) goto Split; Surely this should be if (s (s_limit = L * (TPos)(FT_MAX_CURVE_DEVIATION * 0.75))) goto Split; because the limit is 3/4 of the deviation, times L? Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] latest patch file for spline flattening
That is very interesting and very useful - in fact I think the more surprising a test is, the more useful it is. I'll have to look into your test case carefully as well. I might not be able to do it for a day or to, though. Where does your test data come from? Actual fonts, cooked up data, or a mixture of both? Best regards, Graham - Original Message From: David Bevan david.be...@pb.com To: Graham Asher graham.as...@btinternet.com Cc: freetype-devel freetype-devel@nongnu.org Sent: Tuesday, 7 September, 2010 12:40:21 Subject: RE: [ft-devel] latest patch file for spline flattening Graham, Here are the results of my performance testing. I was a bit surprised by the results. In gray_convert_glyph, the time is distributed as follows: OLDNEW render_line 20%15% render_cubic 15%33% render_scanline 14%10% split_cubic6% 9% OLD is the pre-2.4.0 code; NEW is the latest patch from you. These percentages are the fraction of time spent in the specific function (excluding children). Including children, we have the following actual times per call for handling cubic curves: OLDNEW render_cubic 142us 220us I wasn't expecting your new code to be slower. So I ran my trace code on it with the following results: OLD NEW average line segs per arc13.5 11.3 min line segs per arc 21 max line segs per arc32 133 average deviation per line seg0.29 0.44 min deviation per line seg00 max deviation per line seg 22.2 15.8 Some arcs are creating a very large number of line segments. I expect (though I haven't verified) that it is this that is causing the slow-down. Below is the data for one curve that gets broken down into many tiny line segments. David %^ 4604,0 2080,0 40,2020 40,4496 40,4496 - 40,4436 40,4436 - 40,4379 40,4379 - 41,4321 41,4321 - 44,4264 44,4264 - 47,4206 47,4206 - 51,4149 51,4149 - 56,4092 56,4092 - 62,4036 62,4036 - 68,3979 68,3979 - 74,3922 74,3922 - 81,3865 81,3865 - 90,3811 90,3811 - 99,3754 99,3754 - 109,3700 109,3700 - 119,3645 119,3645 - 131,3591 131,3591 - 142,3535 142,3535 - 154,3481 154,3481 - 166,3427 166,3427 - 181,3373 181,3373 - 195,3319 195,3319 - 210,3265 210,3265 - 225,3211 225,3211 - 243,3160 243,3160 - 259,3106 259,3106 - 277,3055 277,3055 - 295,3002 295,3002 - 314,2951 314,2951 - 333,2900 333,2900 - 354,2849 354,2849 - 375,2798 375,2798 - 397,2748 397,2748 - 418,2697 418,2697 - 440,2646 440,2646 - 463,2595 463,2595 - 487,2547 487,2547 - 536,2450 536,2450 - 588,2354 588,2354 - 641,2258 641,2258 - 697,2165 697,2165 - 756,2073 756,2073 - 817,1984 817,1984 - 879,1894 879,1894 - 943,1807 943,1807 - 1009,1720 1009,1720 - 1079,1637 1079,1637 - 1149,1554 1149,1554 - 1222,1474 1222,1474 - 1297,1395 1297,1395 - 1375,1319 1375,1319 - 1452,1243 1452,1243 - 1533,1169 1533,1169 - 1614,1097 1614,1097 - 1698,1028 1698,1028 - 1782,959 1782,959 - 1869,894 1869,894 - 1958,830 1958,830 - 2049,769 2049,769 - 2140,708 2140,708 - 2233,651 2233,651 - 2328,595 2328,595 - 2425,543 2425,543 - 2522,491 2522,491 - 2570,467 2570,467 - 2621,443 2621,443 - 2671,419 2671,419 - 2722,397 2722,397 - 2773,375 2773,375 - 2825,354 2825,354 - 2876,332 2876,332 - 2927,311 2927,311 - 2978,290 2978,290 - 3031,272 3031,272 - 3082,253 3082,253 - 3136,235 3136,235 - 3190,217 3190,217 - 3244,202 3244,202 - 3297,184 3297,184 - 3351,169 3351,169 - 3405,154 3405,154 - 3460,140 3460,140 - 3514,126 3514,126 - 3570,114 3570,114 - 3625,102 3625,102 - 3682,91 3682,91 - 3736,79 3736,79 - 3793,69 3793,69 - 3849,59 3849,59 - 3906,50 3906,50 - 3963,41 3963,41 - 4020,34 4020,34 - 4077,28 4077,28 - 4136,22 4136,22 - 4193,16 4193,16 - 4251,11 4251,11 - 4308,7 4308,7 - 4368,4 4368,4 - 4425,1 4425,1 - 4485,0 4485,0 - 4544,0 4544,0 - 4604,0 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] latest patch file for spline flattening
With 14,000 glyphs, I imagine that's a CJK font. I think there might be different characteristics from a typical Latin font. I think we also ought to try out a similar number of Latin glyphs, which could be done by rasterizing all the glyphs in a Latin font at varying sizes and rotations. In some ways a CJK font is probably a more stressful test, because strokes occur at a greater number of angles and sizes; but Latin characters should be part of the benchmark. I am not trying to foist more work on you; just musing. Graham - Original Message From: David Bevan david.be...@pb.com To: GRAHAM ASHER graham.as...@btinternet.com Cc: freetype-devel freetype-devel@nongnu.org Sent: Tuesday, 7 September, 2010 13:52:35 Subject: RE: [ft-devel] latest patch file for spline flattening After trying various other fonts, I settled on using a single large (14,000 glyphs; 800,000 Bezier curves) CID-keyed Type 1 font, which seemed to show pretty average behaviour. I'm working on an implementation of something like Hain's algorithm now. It'll be interesting to see how it compares. David %^ -Original Message- From: GRAHAM ASHER [mailto:graham.as...@btinternet.com] Sent: 07 September 2010 13:46 To: David Bevan Cc: freetype-devel Subject: Re: [ft-devel] latest patch file for spline flattening That is very interesting and very useful - in fact I think the more surprising a test is, the more useful it is. I'll have to look into your test case carefully as well. I might not be able to do it for a day or to, though. Where does your test data come from? Actual fonts, cooked up data, or a mixture of both? Best regards, Graham - Original Message From: David Bevan david.be...@pb.com To: Graham Asher graham.as...@btinternet.com Cc: freetype-devel freetype-devel@nongnu.org Sent: Tuesday, 7 September, 2010 12:40:21 Subject: RE: [ft-devel] latest patch file for spline flattening Graham, Here are the results of my performance testing. I was a bit surprised by the results. In gray_convert_glyph, the time is distributed as follows: OLDNEW render_line 20%15% render_cubic 15%33% render_scanline 14%10% split_cubic6% 9% OLD is the pre-2.4.0 code; NEW is the latest patch from you. These percentages are the fraction of time spent in the specific function (excluding children). Including children, we have the following actual times per call for handling cubic curves: OLDNEW render_cubic 142us 220us I wasn't expecting your new code to be slower. So I ran my trace code on it with the following results: OLD NEW average line segs per arc13.5 11.3 min line segs per arc 21 max line segs per arc32 133 average deviation per line seg0.29 0.44 min deviation per line seg00 max deviation per line seg 22.2 15.8 Some arcs are creating a very large number of line segments. I expect (though I haven't verified) that it is this that is causing the slow-down. Below is the data for one curve that gets broken down into many tiny line segments. David %^ 4604,0 2080,0 40,2020 40,4496 40,4496 - 40,4436 40,4436 - 40,4379 40,4379 - 41,4321 41,4321 - 44,4264 44,4264 - 47,4206 47,4206 - 51,4149 51,4149 - 56,4092 56,4092 - 62,4036 62,4036 - 68,3979 68,3979 - 74,3922 74,3922 - 81,3865 81,3865 - 90,3811 90,3811 - 99,3754 99,3754 - 109,3700 109,3700 - 119,3645 119,3645 - 131,3591 131,3591 - 142,3535 142,3535 - 154,3481 154,3481 - 166,3427 166,3427 - 181,3373 181,3373 - 195,3319 195,3319 - 210,3265 210,3265 - 225,3211 225,3211 - 243,3160 243,3160 - 259,3106 259,3106 - 277,3055 277,3055 - 295,3002 295,3002 - 314,2951 314,2951 - 333,2900 333,2900 - 354,2849 354,2849 - 375,2798 375,2798 - 397,2748 397,2748 - 418,2697 418,2697 - 440,2646 440,2646 - 463,2595 463,2595 - 487,2547 487,2547 - 536,2450 536,2450 - 588,2354 588,2354 - 641,2258 641,2258 - 697,2165 697,2165 - 756,2073 756,2073 - 817,1984 817,1984 - 879,1894 879,1894 - 943,1807 943,1807 - 1009,1720 1009,1720 - 1079,1637 1079,1637 - 1149,1554 1149,1554 - 1222,1474 1222,1474 - 1297,1395 1297,1395 - 1375,1319 1375,1319 - 1452,1243 1452,1243 - 1533,1169 1533,1169 - 1614,1097 1614,1097 - 1698,1028 1698,1028 - 1782,959 1782,959 - 1869,894 1869,894 - 1958,830 1958,830 - 2049,769 2049,769 - 2140,708 2140,708 - 2233,651 2233,651 - 2328,595 2328,595 - 2425,543 2425,543 - 2522,491 2522,491 - 2570,467 2570,467 - 2621,443 2621,443 - 2671,419 2671,419 - 2722,397 2722,397 - 2773,375 2773,375 - 2825,354 2825,354 - 2876,332 2876,332 - 2927,311 2927,311 - 2978,290 2978,290 - 3031,272 3031,272 - 3082,253 3082,253 - 3136,235 3136,235 - 3190,217 3190,217 - 3244,202 3244,202 - 3297,184 3297,184 - 3351,169
Re: [ft-devel] FT_MulFix assembly
Have you done an ARM version? Forgive my inattentiveness if you've
already announced one. It just struck me that this sort of optimisation
is even more necessary on mobile devices.
Graham
James Cloos wrote:
The final result for amd64 looks like:
static __inline__ long
FT_MulFix_x86_64( long a,
long b )
{
register long result;
__asm__ __volatile__ (
movq %1, %%rax\n
imul %2\n
addq %%rdx, %%rax\n
addq $0x8000, %%rax\n
sarq $16, %%rax\n
: =a(result)
: g(a), g(b)
: rdx );
return result;
}
The use of long, though requires review. The C version uses FT_Long
(not FT_Int32 like the other asm versions), but FT_Long is not a #define
or a typedef at the point where the asm version are located.
That said, using long there on amd64 prevents unnecessary 32-64 bit
conversions in the resulting code.
The above code has a latency of 1+5+1+1+1 = 10 clocks on an amdfam10 cpu.
The assembly generated by the C code is 45 lines and 158 octets long,
contains six conditional jumps, three each of explicit compares and
tests, and still benchmarks are just as fast. Out-of-order processing
wins out over hand-coded asm. :-/
It *might* make more of a difference on an in-order processor like the
Arom. But I do not have one to test.
I can still finish a patch, and have collected the info I need to do one
for mips64, too, where I expect it will be more important. I also expect
that the i386 version could be tidied a bit.
Is the amd64 version desired, given how little benefit it has?
-JimC
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] latest patch file for spline flattening
Here's a new version of my spline flattening patch. (I would like to be
able to push this to the git repository but am having authentication
problems; Werner has been helping me, but no success so far, probably
because of my ineptitude in these matters.).
The nub of the latest change is that I found that predicting the number
of recursion levels is not reliable when splitting a cubic spline for
flattening. A better way is to check the flatness inside the loop -
using the fast heuristic of taking the maximum coordinate difference of
a control point from the chord midpoint. This also makes the code
simpler - and, surprisingly, faster, according to my benchmark; however,
my benchmark is based on cartographic, not typographic, use, so will
need confirmation.
The patch obviously still solves the bug involving s-shaped curves
(control points on both sides of the chord).
Graham
diff --git a/C:\\DOCUME~1\\Graham\\LOCALS~1\\Temp\\ftgrays_c8f5b9.c
b/C:\\FreeType\\freetype2\\src\\smooth\\ftgrays.c
index 0b94143..3a5e3cf 100644
--- a/C:\\DOCUME~1\\Graham\\LOCALS~1\\Temp\\ftgrays_c8f5b9.c
+++ b/C:\\FreeType\\freetype2\\src\\smooth\\ftgrays.c
@@ -90,6 +90,9 @@
#undef FT_COMPONENT
#define FT_COMPONENT trace_smooth
+/* The maximum distance of a curve from the chord, in 64ths of a pixel; */
+/* used when flattening curves. */
+#define FT_MAX_CURVE_DEVIATION 16
#ifdef _STANDALONE_
@@ -354,8 +357,6 @@ typedef ptrdiff_t FT_PtrDist;
int band_size;
int band_shoot;
-int conic_level;
-int cubic_level;
ft_jmp_buf jump_buffer;
@@ -888,31 +889,18 @@ typedef ptrdiff_t FT_PtrDist;
if ( dx dy )
dx = dy;
-level = 1;
-dx = dx / ras.conic_level;
-while ( dx 0 )
+if ( dx = FT_MAX_CURVE_DEVIATION )
{
- dx = 2;
- level++;
+ gray_render_line( RAS_VAR_ UPSCALE( to-x ), UPSCALE( to-y ) );
+ return;
}
-/* a shortcut to speed things up */
-if ( level = 1 )
+level = 1;
+dx /= FT_MAX_CURVE_DEVIATION;
+while ( dx 1 )
{
- /* we compute the mid-point directly in order to avoid */
- /* calling gray_split_conic() */
- TPos to_x, to_y, mid_x, mid_y;
-
-
- to_x = UPSCALE( to-x );
- to_y = UPSCALE( to-y );
- mid_x = ( ras.x + to_x + 2 * UPSCALE( control-x ) ) / 4;
- mid_y = ( ras.y + to_y + 2 * UPSCALE( control-y ) ) / 4;
-
- gray_render_line( RAS_VAR_ mid_x, mid_y );
- gray_render_line( RAS_VAR_ to_x, to_y );
-
- return;
+ dx = 2;
+ level++;
}
arc = ras.bez_stack;
@@ -957,21 +945,9 @@ typedef ptrdiff_t FT_PtrDist;
}
Draw:
- {
-TPos to_x, to_y, mid_x, mid_y;
-
-
-to_x = arc[0].x;
-to_y = arc[0].y;
-mid_x = ( ras.x + to_x + 2 * arc[1].x ) / 4;
-mid_y = ( ras.y + to_y + 2 * arc[1].y ) / 4;
-
-gray_render_line( RAS_VAR_ mid_x, mid_y );
-gray_render_line( RAS_VAR_ to_x, to_y );
-
-top--;
-arc -= 2;
- }
+ gray_render_line( RAS_VAR_ arc[0].x, arc[0].y );
+ top--;
+ arc -= 2;
}
return;
@@ -1011,56 +987,9 @@ typedef ptrdiff_t FT_PtrDist;
const FT_Vector* control2,
const FT_Vector* to )
{
-int top, level;
-int*levels;
FT_Vector* arc;
-int mid_x = ( DOWNSCALE( ras.x ) + to-x +
- 3 * (control1-x + control2-x ) ) / 8;
-int mid_y = ( DOWNSCALE( ras.y ) + to-y +
- 3 * (control1-y + control2-y ) ) / 8;
-TPosdx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
-TPosdy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
-if ( dx 0 )
- dx = -dx;
-if ( dy 0 )
- dy = -dy;
-if ( dx dy )
- dx = dy;
-
-level = 1;
-dx /= ras.cubic_level;
-while ( dx 0 )
-{
- dx = 2;
- level++;
-}
-
-if ( level = 1 )
-{
- TPos to_x, to_y;
-
-
- to_x = UPSCALE( to-x );
- to_y = UPSCALE( to-y );
-
- /* Recalculation of midpoint is needed only if */
- /* UPSCALE and DOWNSCALE have any effect. */
-
-#if ( PIXEL_BITS != 6 )
- mid_x = ( ras.x + to_x +
-3 * UPSCALE( control1-x + control2-x ) ) / 8;
- mid_y = ( ras.y + to_y +
-3 * UPSCALE( control1-y + control2-y ) ) / 8;
-#endif
-
- gray_render_line( RAS_VAR_ mid_x, mid_y );
- gray_render_line( RAS_VAR_ to_x, to_y );
-
- return;
-}
-
arc = ras.bez_stack;
arc[0].x = UPSCALE( to-x );
arc[0].y = UPSCALE( to-y );
@@ -1071,56 +1000,66 @@ typedef ptrdiff_t FT_PtrDist;
arc[3].x = ras.x;
arc[3].y = ras.y;
-levels= ras.lev_stack;
-top = 0;
-levels[0] = level;
-
-while ( top = 0 )
+for (;;)
{
- level = levels[top];
- if ( level 1 )
- {
-/* check
Re: [ft-devel] latest patch file for spline flattening
David, in fact I coded up and tested a different version using an accurate calculation of the control point deviation, but it was slower than the version I am proposing. I'll try your version; and I would be grateful if you could also do some benchmarking, because obviously we are not trying to minimise the number of straight line segments the curve is dissected into, but the overall speed. My aims, and my benchmarking, are rather biased, because my main use of cubic splines is for approximations to arcs of circles, used as parts of path envelopes when drawing maps. Graham David Bevan wrote: Graham, That's looking much closer to what I would have thought we needed; only splitting the curve when required. However, your fast heuristic can be very inaccurate. Consider P0: 0,0 P1: 5,5 P2: 95,5 P3: 100,0 The max deviation is 3.75 (0.75 * 5 since Hain's v == 1), but your heuristic gives a value of 45 - twelve times too great. Btw, I think that dx1, dy1, ... need to be of type TPos, not int. On the issue of avoiding square roots, a little bit of algebra shows that it is possible to estimate r = sqrt(dx^2 + dy^2) with a simple linear combination of dx and dy. For example, if an overestimate is required, and dx = dy, you can use r_upperbound = dx + (sqrt(2) - 1) * dy which overestimates by no more than 8.5%. For integer arithmetic, sqrt(2) - 1 can be (over)estimated by 107/256. For example, you could use this approximation to do something like this: dx1 = abs(control1-x - midx); dy1 = abs(control1-y - midy); if (dx1 = dy1) dr1 = dx1 + (107 * dy1 + 255) 8; else dr1 = dy1 + (107 * dx1 + 255) 8; dx2 = abs(control2-x - midx); dy2 = abs(control2-y - midy); if (dx2 = dy2) dr2 = dx2 + (107 * dy2 + 255) 8; else dr2 = dy2 + (107 * dx2 + 255) 8; /* deviation never exceeds 75% of control point dist */ if (dr1 = dr2) dev_max = (3 * dr1 + 3) 2; else dev_max = (3 * dr2 + 3) 2; if (dev_max = FT_MAX_CURVE_DEVIATION) ... Of course, this doesn't resolve the problem I mentioned above; for the example curve, this gives dev_max a value of 36 - still nine times too great. I hope to have something based a bit more closely on Hain's paper by the end of tomorrow. I may use something like the square-root avoiding estimate above to approximate his L value. David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of Graham Asher Sent: 6 September 2010 11:10 To: freetype-devel Subject: [ft-devel] latest patch file for spline flattening Here's a new version of my spline flattening patch. (I would like to be able to push this to the git repository but am having authentication problems; Werner has been helping me, but no success so far, probably because of my ineptitude in these matters.). The nub of the latest change is that I found that predicting the number of recursion levels is not reliable when splitting a cubic spline for flattening. A better way is to check the flatness inside the loop - using the fast heuristic of taking the maximum coordinate difference of a control point from the chord midpoint. This also makes the code simpler - and, surprisingly, faster, according to my benchmark; however, my benchmark is based on cartographic, not typographic, use, so will need confirmation. The patch obviously still solves the bug involving s-shaped curves (control points on both sides of the chord). Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] more thoughts on cubic spline flattening
Here's a patch for review. As you know I have also started the process
of registering as a contributor, so I might be able to commit directly
if you like.
Graham
Werner LEMBERG wrote:
Some brief comments inline.
More feedback from my investigations later. [...]
BTW, thanks a lot to both of you for working on this! Is there
something which I shall already commit to the repository?
Werner
281daa355bf9a3f335dc75773188d68075e4af98
src/smooth/ftgrays.c | 164 --
1 files changed, 51 insertions(+), 113 deletions(-)
diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c
index 0b94143..7c6afb0 100644
--- a/src/smooth/ftgrays.c
+++ b/src/smooth/ftgrays.c
@@ -90,6 +90,8 @@
#undef FT_COMPONENT
#define FT_COMPONENT trace_smooth
+/* The maximum distance of a curve from the chord, in 64ths of a pixel; used
when flattening curves. */
+#define FT_MAX_CURVE_DEVIATION 16
#ifdef _STANDALONE_
@@ -354,8 +356,6 @@ typedef ptrdiff_t FT_PtrDist;
int band_size;
int band_shoot;
-int conic_level;
-int cubic_level;
ft_jmp_buf jump_buffer;
@@ -878,7 +878,6 @@ typedef ptrdiff_t FT_PtrDist;
int*levels;
FT_Vector* arc;
-
dx = DOWNSCALE( ras.x ) + to-x - ( control-x 1 );
if ( dx 0 )
dx = -dx;
@@ -888,31 +887,18 @@ typedef ptrdiff_t FT_PtrDist;
if ( dx dy )
dx = dy;
-level = 1;
-dx = dx / ras.conic_level;
-while ( dx 0 )
+ if ( dx = FT_MAX_CURVE_DEVIATION )
{
- dx = 2;
- level++;
+ gray_render_line( RAS_VAR_ UPSCALE( to-x ), UPSCALE( to-y ) );
+ return;
}
-/* a shortcut to speed things up */
-if ( level = 1 )
+level = 1;
+dx /= FT_MAX_CURVE_DEVIATION;
+while ( dx 1 )
{
- /* we compute the mid-point directly in order to avoid */
- /* calling gray_split_conic() */
- TPos to_x, to_y, mid_x, mid_y;
-
-
- to_x = UPSCALE( to-x );
- to_y = UPSCALE( to-y );
- mid_x = ( ras.x + to_x + 2 * UPSCALE( control-x ) ) / 4;
- mid_y = ( ras.y + to_y + 2 * UPSCALE( control-y ) ) / 4;
-
- gray_render_line( RAS_VAR_ mid_x, mid_y );
- gray_render_line( RAS_VAR_ to_x, to_y );
-
- return;
+ dx = 2;
+ level++;
}
arc = ras.bez_stack;
@@ -957,21 +943,9 @@ typedef ptrdiff_t FT_PtrDist;
}
Draw:
- {
-TPos to_x, to_y, mid_x, mid_y;
-
-
-to_x = arc[0].x;
-to_y = arc[0].y;
-mid_x = ( ras.x + to_x + 2 * arc[1].x ) / 4;
-mid_y = ( ras.y + to_y + 2 * arc[1].y ) / 4;
-
-gray_render_line( RAS_VAR_ mid_x, mid_y );
-gray_render_line( RAS_VAR_ to_x, to_y );
-
-top--;
-arc -= 2;
- }
+ gray_render_line( RAS_VAR_ arc[0].x, arc[0].y );
+ top --;
+ arc -= 2;
}
return;
@@ -1014,51 +988,45 @@ typedef ptrdiff_t FT_PtrDist;
int top, level;
int*levels;
FT_Vector* arc;
-int mid_x = ( DOWNSCALE( ras.x ) + to-x +
- 3 * (control1-x + control2-x ) ) / 8;
-int mid_y = ( DOWNSCALE( ras.y ) + to-y +
- 3 * (control1-y + control2-y ) ) / 8;
-TPosdx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
-TPosdy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
-
-
-if ( dx 0 )
- dx = -dx;
-if ( dy 0 )
- dy = -dy;
-if ( dx dy )
- dx = dy;
-
-level = 1;
-dx /= ras.cubic_level;
-while ( dx 0 )
+
+/*
+ Estimate the furthest distance of a coordinate of a control point from
the
+ midpoint of the chord.
+ */
+ TPos dx1, dy1, dx2, dy2;
+ int midx = ( DOWNSCALE( ras.x ) + to-x ) / 2;
+ int midy = ( DOWNSCALE( ras.y ) + to-y ) / 2;
+ dx1 = control1-x - midx;
+if ( dx1 0 )
+ dx1 = -dx1;
+ dy1 = control1-y - midy;
+if ( dy1 0 )
+ dy1 = -dy1;
+ dx2 = control2-x - midx;
+if ( dx2 0 )
+ dx2 = -dx2;
+ dy2 = control2-y - midy;
+if ( dy2 0 )
+ dy2 = -dy2;
+ if ( dx1 dy1 )
+ dx1 = dy1;
+ if ( dx1 dx2 )
+ dx1 = dx2;
+ if ( dx1 dy2 )
+ dx1 = dy2;
+
+ if ( dx1 = FT_MAX_CURVE_DEVIATION )
{
- dx = 2;
- level++;
+ gray_render_line( RAS_VAR_ to-x, to-y );
+ return;
}
-if ( level = 1 )
+level = 1;
+dx1 /= FT_MAX_CURVE_DEVIATION;
+while ( dx1 1 )
{
- TPos to_x, to_y;
-
-
- to_x = UPSCALE( to-x );
- to_y = UPSCALE( to-y );
-
- /* Recalculation of midpoint is needed only if */
- /* UPSCALE and DOWNSCALE have any effect. */
-
-#if ( PIXEL_BITS != 6 )
- mid_x = ( ras.x + to_x +
-3 * UPSCALE( control1-x + control2-x ) ) / 8;
- mid_y = ( ras.y + to_y +
-3 * UPSCALE( control1-y + control2-y ) ) / 8;
-#endif
-
-
Re: [ft-devel] more thoughts on cubic spline flattening
I have finally got round to installing TortoiseGit on the computer I'm using for this, and have cloned the repository, so I shall be able to give you a patch that will fix the bug reported by Stefan (still don't know his surname) and correct the other bug I noticed - the strange relaxation of the flattening criterion for large glyphs. I should be able to get something to you tomorrow. No need to thank me for working on this - it is of vital importance to my bread and butter - and beer. FreeType has been part of my career since 1998, so in fact I owe you and David and the other contributors more than I can repay. I am continually embarrassed by how little I work on improving FreeType. Graham Werner LEMBERG wrote: Some brief comments inline. More feedback from my investigations later. [...] BTW, thanks a lot to both of you for working on this! Is there something which I shall already commit to the repository? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] more thoughts on cubic spline flattening
David Bevan's citation of two papers on spline flattening (http://www.cis.southalabama.edu/~hain/general/Publications/Bezier/Camera-ready%20CISST02%202.pdf and http://www.cis.usouthal.edu/~hain/general/Publications/Bezier/bezier%20cccg04%20paper.pdf) stimulated some more thoughts on the problem. To recapitulate some existing points, and ask some more questions, and point out another error in the current FreeType logic (point 6): 1. The ideal flattening criterion is the maximum deviation (sideways distance) of any point on the curve from the chord (straight line from p0 to p3; not the line segment, but the whole infinite line). 2. Hain's paper shows that this can be approximated (yielding an estimate that is never too small, and always quite close) by a quadratic equation based on the ratio between the deviations of the two control points from the chord. If the ratio (smaller deviation divided by larger) is v, the expression 0.072(v^2) + 0.229v + 0.449, multiplied by the larger of the two deviations, gives this approximation. 3. Calculating the expression in (2) is quite expensive because square root operations are required to get the deviations of the two control points, and some fixed-point arithmetic is needed to avoid or at least minimise overflow. (I have coded this experimentally.) 4. There are a series of less accurate heuristics. The first relaxation is not to evaluate the expression in (2), but to use the value 0.75, which is the maximum value it can yield (v is always in the range 0...1, and v=1 yields 0.75; smaller values of v give smaller results). However, this heuristic still requires calculation of the deviations of the control points. A second relaxation uses the maximum coordinate distance (max of dx and dy) of a control point from the middle of the chord, which cannot be less than the actual deviation. 5. Therefore a usable fast heuristic is the maximum coordinate distance from the middle of the chord, multiplied by 0.75. 6. Unfortunately the current logic in FreeType has another error. It assumes that the flattening criterion can be applied at the start, yielding the required number of bisections. That is, a ratio is calculated between the heuristic distance and a so-called 'cubic level'; and the number of bisections needed is calculated as the ceiling of the base-4 logarithm of the heuristic distance; in other words, there is an assumption that every bisection of a cubic spline increases its flatness fourfold. 7. Here is the proof that the assumption in (6) is wrong. A cubic spline with control points on different sides of the chord, symmetrically arranged, will be bisected at the point where it crosses the chord. The two halves will have exactly the same maximum deviation as the whole. This leads to the big question. Is it possible to determine the minimum number of bisections needed at the start, using a formula that does not itself apply the bisections - that is, something simpler than the exhaustive calculation? (Perhaps flatness does increase fourfold if the control points are the same side of the chord, so all we need do is add one iteration for an initial contrary case.) I suspect that the answer is no, but I am sure David Bevan will want to comment. If the answer is no, then I shall need to code up a fix that estimates flatness efficiently on each iteration of the bisection loop. Comments please. Thanks in advance, Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] more thoughts on cubic spline flattening
David, you are of course correct that my point 5 is wrong. That is just carelessness on my part. Some clarifications: You point out that p0 and p3 can have coordinates outside the range 0...1 in Hain's r/s system. I deliberately ignore that, and I should have explained why in more explicit terms. The aim of FreeType is to rasterize the outline of a closed curve, and for this purpose I believe that, just as we can ignore deviations from the curve of greater than a certain tolerance, we can ignore spikes with maximum width less than that tolerance. P0 and P3 coordinates of this type create such spikes. But if we a heuristic based on the maximum distance of control point coordinates from the middle of the chord, the problem doesn't arise anyway. It arises only if we use Hain's algorithm fully. You said my reading of Hain's paper is that the evaluation of square roots is never actually needed. To get the deviations of the control points we need to either (i) rotate the points into the r/s coordinate system, and the simplest way of creating a rotation transform requires square roots (convert chord vector to unit vector by dividing by vector length obtained by Pythagoras, then sine and cosine needed for transform are x and y coords of vector); or (ii) use the standard method of finding the distance of a point from a line, which again needs Pythagoras to get the lengths of vectors. I hope I've missed some simpler way of doing it, in which case please tell me. In answer to your question A: the units are 64ths of a pixel, so 16 is a quarter pixel. That is for the normal case; FreeType can be configured to use different numbers of bits per pixel. The controlling macro is PIXEL_BITS in ftgrays.c In answer to question B: I don't know; perhaps Werner can answer. I don't follow everything on the FreeType list, and have long periods when I haven't time to look at anything. In answer to question C: yes, I posted the font and screen shots to the list a few days ago - and I see that Werner has just linked to it in his latest post. Graham David Bevan wrote: Graham, I finally had a brief chance to look at the code yesterday, and hope to be able to spend most of the rest of today on it too. (So far I have only looked at the pre-2.4.0 code.) gray_render_cubic is a (non-recursive implementation of) a recursive algorithm for splitting the curve into 2^n line segments. This is forward differencing rather than recursive subdivision (which determine whether each subdivision is required independently). At the moment I don't understand the basis for the calculation of n, though I presume that it is some standard heuristic. You point 7 below rather brings that into doubt though! This was probably state-of-the-art when it was first implemented, but is probably quite inefficient in the number of line segments created. I've added further comments inline below, and some queries at the end. -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of GRAHAM ASHER Sent: 3 September 2010 09:14 To: FreeType Subject: [ft-devel] more thoughts on cubic spline flattening David Bevan's citation of two papers on spline flattening (http://www.cis.southalabama.edu/~hain/general/Publications/Bezier/Camera- ready%20CISST02%202.pdf and http://www.cis.usouthal.edu/~hain/general/Publications/Bezier/bezier%20ccc g04%20paper.pdf) stimulated some more thoughts on the problem. To recapitulate some existing points, and ask some more questions, and point out another error in the current FreeType logic (point 6): 1. The ideal flattening criterion is the maximum deviation (sideways distance) of any point on the curve from the chord (straight line from p0 to p3; not the line segment, but the whole infinite line). This isn't quite the whole story. The curve may extend outside the infinite strip perpendicular to the chord P0P3 as seen in Hain's Figure 2. Indeed it may do so even if the curve never deviates from the chord in the s-direction by more than the maximum acceptable deviation value (because both control points are very close to the line which extends the chord). This is the reason for Hain's section 3.2 on the longitudinal deviation. However, there's a simple approach for handling this: if P0 or P3 is (more than the maximum acceptable deviation value) outside the strip, subdivide. Hain mentions this at the end of his section 1. 2. Hain's paper shows that this can be approximated (yielding an estimate that is never too small, and always quite close) by a quadratic equation based on the ratio between the deviations of the two control points from the chord. If the ratio (smaller deviation divided by larger) is v, the expression 0.072(v^2) + 0.229v + 0.449, multiplied by the larger of the two deviations, gives this approximation. 3. Calculating the expression in (2
Re: [ft-devel] a satisfactory fix for the cubic spline bug
David,
Thank you very much for the citations, which are very interesting, but I don't
think anybody is proposing reinventing anything - least of all me. The problem
here is not whether there are known rigorous methods of determining the
flatness
of a curve. We are looking for a very fast heuristic that reduces the number of
bisections of a cubic spline to the minimum in most cases, and behaves
reasonably in other cases; in that it never reduces the number of bisections
below the minimum, or produces far too many.
Any system that always results in at least as many bisections as the minimum
number required to flatten the curve to satisfy our definition of flatness, and
does not enter an infinite loop, will give correct output.We know how to do the
job correctly; the problem is doing it fast.
After looking at the papers you cite for a short while my impression is that
they cannot easily be used without floating-point arithmetic, which is not used
in FreeType (and that policy certainly won't be relaxed for a while, I am
sure).
Fixed-point is never a satisfactory substitute where multiplication and
squaring
of coordinates is used, because it can easily lead to overflows of the need for
elaborate work-arounds for overflows. Methods relying on the cubic spline
formula will inevitably require cubes of coordinates. FreeType works in 64ths
of
pixels, so in signed 32-bit arithmetic we are restricted to a maximum
coordinate
size of sqrt(2^31) = 1290 64ths, or 20 pixels, which makes it impossible. The
method described in the first paper you cite requires as a starting point the
distance of the control points from the straight line, which needs squares and
square roots, posing more problems for integer overflow and speed.
If you can code up a better fix than mine, using one of the algorithms you
cite,
I will be very happy to withdraw my suggestion in favour of yours. I think an
insuperable difficulty will be the possibility of overflow and the speed of the
code. I hope to be proved wrong!
Best regards,
Graham
- Original Message
From: David Bevan david.be...@pb.com
To: freetype-devel freetype-devel@nongnu.org
Sent: Tuesday, 31 August, 2010 9:14:36
Subject: RE: [ft-devel] a satisfactory fix for the cubic spline bug
Rather than piecemeal reinventing of the wheel, I would have thought that FT
should implement a mathematically rigorous flattener. The following might be a
good place to start:
http://www.cis.southalabama.edu/~hain/general/Publications/Bezier/Camera-ready%20CISST02%202.pdf
Or:
http://www.cis.usouthal.edu/~hain/general/Publications/Bezier/bezier%20cccg04%20paper.pdf
Naively, I had assumed that this sort of issue would have been resolved
properly
back in the pre-history of FT, since it is obviously of critical importance for
correct output.
Since it apparently hasn't been, we can make use of the latest research.
David %^
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
Graham Asher
Sent: 30 August 2010 10:59
To: freetype-devel
Subject: [ft-devel] a satisfactory fix for the cubic spline bug
I thought about this overnight and realised that we can slightly modify
the existing heuristic to get a much simpler fix. Instead of trying to
find points on the curve or trying to measure the distance from a point
to a straight line, we adapt the earlier idea, used in existing FreeType
code, of finding the maximum coordinate difference (that is, whichever
is greater of dx and dy):
* existing method: use max coordinate difference between middle of
spline, found by bisection, and middle of straight line
* new method: use max coordinate difference between either of the two
control points and the middle of the straight line
This yields the following code (start of gray_render_cubic), which
works, fixes the bug, and is probably faster, because it is certainly
simpler. I don't think I'll go any further than this.
static int
gray_render_cubic( RAS_ARG_ FT_Vector* control1,
FT_Vector* control2,
FT_Vector* to )
{
int top, level;
int*levels;
FT_Vector* arc;
int error = 0;
/*
Find the furthest distance of a coordinate of a control point from the
midpoint of the line.
*/
int dx1, dy1, dx2, dy2;
int midx = (DOWNSCALE(ras.x) + to-x) / 2;
int midy = (DOWNSCALE(ras.y) + to-y) / 2;
dx1 = control1-x - midx; if (dx1 0) dx1 = -dx1;
dy1 = control1-y - midy; if (dy1 0) dy1 = -dy1;
dx2 = control2-x - midx; if (dx2 0) dx2 = -dx2;
dy2 = control2-y - midy; if (dy2 0) dy2 = -dy2;
if (dx1 dy1)
dx1 = dy1;
if (dx1 dx2)
dx1 = dx2;
if (dx1 dy2)
dx1 = dy2;
if (dx1 = ras.cubic_level)
return gray_render_line( RAS_VAR_ to-x, to-y
Re: [ft-devel] a satisfactory fix for the cubic spline bug
Correction: for we are restricted to a maximum coordinate
size of sqrt(2^31) read we are restricted to a maximum coordinate
size of the cube root of 2^31
- Original Message
From: GRAHAM ASHER graham.as...@btinternet.com
To: David Bevan david.be...@pb.com; freetype-devel freetype-devel@nongnu.org
Sent: Tuesday, 31 August, 2010 12:18:45
Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug
David,
Thank you very much for the citations, which are very interesting, but I don't
think anybody is proposing reinventing anything - least of all me. The problem
here is not whether there are known rigorous methods of determining the
flatness
of a curve. We are looking for a very fast heuristic that reduces the number of
bisections of a cubic spline to the minimum in most cases, and behaves
reasonably in other cases; in that it never reduces the number of bisections
below the minimum, or produces far too many.
Any system that always results in at least as many bisections as the minimum
number required to flatten the curve to satisfy our definition of flatness, and
does not enter an infinite loop, will give correct output.We know how to do the
job correctly; the problem is doing it fast.
After looking at the papers you cite for a short while my impression is that
they cannot easily be used without floating-point arithmetic, which is not used
in FreeType (and that policy certainly won't be relaxed for a while, I am
sure).
Fixed-point is never a satisfactory substitute where multiplication and
squaring
of coordinates is used, because it can easily lead to overflows of the need for
elaborate work-arounds for overflows. Methods relying on the cubic spline
formula will inevitably require cubes of coordinates. FreeType works in 64ths
of
pixels, so in signed 32-bit arithmetic we are restricted to a maximum
coordinate
size of sqrt(2^31) = 1290 64ths, or 20 pixels, which makes it impossible. The
method described in the first paper you cite requires as a starting point the
distance of the control points from the straight line, which needs squares and
square roots, posing more problems for integer overflow and speed.
If you can code up a better fix than mine, using one of the algorithms you
cite,
I will be very happy to withdraw my suggestion in favour of yours. I think an
insuperable difficulty will be the possibility of overflow and the speed of the
code. I hope to be proved wrong!
Best regards,
Graham
- Original Message
From: David Bevan david.be...@pb.com
To: freetype-devel freetype-devel@nongnu.org
Sent: Tuesday, 31 August, 2010 9:14:36
Subject: RE: [ft-devel] a satisfactory fix for the cubic spline bug
Rather than piecemeal reinventing of the wheel, I would have thought that FT
should implement a mathematically rigorous flattener. The following might be a
good place to start:
http://www.cis.southalabama.edu/~hain/general/Publications/Bezier/Camera-ready%20CISST02%202.pdf
Or:
http://www.cis.usouthal.edu/~hain/general/Publications/Bezier/bezier%20cccg04%20paper.pdf
Naively, I had assumed that this sort of issue would have been resolved
properly
back in the pre-history of FT, since it is obviously of critical importance for
correct output.
Since it apparently hasn't been, we can make use of the latest research.
David %^
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
Graham Asher
Sent: 30 August 2010 10:59
To: freetype-devel
Subject: [ft-devel] a satisfactory fix for the cubic spline bug
I thought about this overnight and realised that we can slightly modify
the existing heuristic to get a much simpler fix. Instead of trying to
find points on the curve or trying to measure the distance from a point
to a straight line, we adapt the earlier idea, used in existing FreeType
code, of finding the maximum coordinate difference (that is, whichever
is greater of dx and dy):
* existing method: use max coordinate difference between middle of
spline, found by bisection, and middle of straight line
* new method: use max coordinate difference between either of the two
control points and the middle of the straight line
This yields the following code (start of gray_render_cubic), which
works, fixes the bug, and is probably faster, because it is certainly
simpler. I don't think I'll go any further than this.
static int
gray_render_cubic( RAS_ARG_ FT_Vector* control1,
FT_Vector* control2,
FT_Vector* to )
{
int top, level;
int*levels;
FT_Vector* arc;
int error = 0;
/*
Find the furthest distance of a coordinate of a control point from the
midpoint of the line.
*/
int dx1, dy1, dx2, dy2;
int midx = (DOWNSCALE(ras.x) + to-x) / 2;
int midy = (DOWNSCALE(ras.y
Re: [ft-devel] a satisfactory fix for the cubic spline bug
David, some points on what I think is a rather severe disquisition on your part: (i) You over-react to my use of the word 'hack', which was light-hearted and self-deprecatory. Yes, my original fix was incorrect, and I have now found one that I am satisfied is correct. This is a normal process in software development. Unfortunately nobody understands FreeType fully any more. This is a bad situation, but somewhat mitigated by the number of eyes on the problem, and the number of users willing to test the code. A full suite of regression tests, isolating each module and algorithm, would be great. If you do end up with some time, please consider writing some. I did not check in the fix. I merely proposed it, hoping for comments and improvements. I am very busy and any help is welcome. (ii) The error in gray_render_cubic was gross. It didn't cause a slight inefficiency; it resulted in a very great number of unnecessary bisections. (iii) Although there are provably correct mathematical algorithms, converting them to provably correct computer programs is non-trivial - in fact, impossible outside small toy problems. Your statement Better to keep the inefficiency than (a) break the functionality, and (b) end up with code that is not obviously correct. is laudable, but substantive code that is obviously correct doesn't exist in this world. (iv) The phrase Fixes are now being proposed to the hack, and this is being done by someone who states that they are somewhat ignorant of the mathematics of cubic splines. is strange. Why the passive voice and the use of someone? It's still me, and my name appears on the e-mails. I have been working on and off with cubic splines since about 1986. No, my degree is not in mathematics, but I am not ignorant of these matters. (v) Congratulations on your degree. I hope you have time to use your mathematical knowledge to help with this problem. (vi) Out of interest, please give an example, with coordinates, of a cubic spline with both control points on the same side of the straight line from start to end, for which the midpoint of the curve, as defined by bisection, is not the point of maximum deviation. Best regards, Graham From: David Bevan david.be...@pb.com To: GRAHAM ASHER graham.as...@btinternet.com; freetype-devel freetype-devel@nongnu.org Sent: Tuesday, 31 August, 2010 14:01:43 Subject: RE: [ft-devel] a satisfactory fix for the cubic spline bug Graham/Werner, Perhaps I have misunderstood something. If so, I apologize. I hadn't been following this closely until I noticed an email saying that the curve flattening algorithm failed under some circumstances. That seemed very shocking to me. I would have presumed that the flattening algorithm would be defined in a mathematically rigorous manner and hence would be known to always work (bar any 'typos' in the code). Checking through the ft-devel archive suggests that the beginning of this issue was the message of 7th June, which starts, I have discovered a possible inefficiency in gray_render_cubic in ftsmooth.c. Removing it (by means of what I admit is a hack based on a limited understanding of the code) gives a vast speedup with no apparent loss of quality. For something as critical as the curve flattening, I wouldn't consider a hack of any sort appropriate. I haven't followed the message trail in detail but my understanding is that some version of this hack was accepted into the source and was subsequently shown to be incorrect. Fixes are now being proposed to the hack, and this is being done by someone who states that they are somewhat ignorant of the mathematics of cubic splines. If I was managing this project, I would certainly consider this an unacceptable approach / sequence of events. Better to keep the inefficiency than (a) break the functionality, and (b) end up with code that is not obviously correct. I didn't respond to the following query earlier: If there are any good mathematicians out there (better than me at this, which sets quite a low bar), please confirm that no point on a cubic spline curve with both control points on the same side of the straight line from start to end can be further from the line than the curve's midpoint as defined by bisection of the curve. A simple continuity/smoothness argument shows that the maximum deviation of a cubic spline is not always at the curve's midpoint: If with the control points on either side, the maximal deviation can be elsewhere, and a smooth movement of the control points leads to a smooth change in the curve then the position of the maximal deviation moves smoothly too (and hence is in fact hardly ever actually at the mid-point). I don't have time to investigate this in detail for a while, but might be able to do so sometime next week. David %^ P.S. I have a degree in mathematics from Oxford University. -Original Message- From
Re: [ft-devel] a satisfactory fix for the cubic spline bug
And putting this equation into more standard quadratic form I get d_norm(v) = 0.072(v^2) + 0.229v + 0.449 which yields 0.75 as expected for v = 1, so it looks as though I have the right equation here. Graham From: GRAHAM ASHER graham.as...@btinternet.com To: David Bevan david.be...@pb.com Sent: Tuesday, 31 August, 2010 17:07:52 Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug Can you give the workings? The equation I think you mean is this one: 0.07200(v + 3.180556)v + 0.449000, so when I substitute 0.1 for v I get 0.07200(0.1 + 3.180556)0.1 + 0.449000 which gives 0.47262, and multiplying that by 50, the maximum deviation of a control point, gives 23.631, not your y value, so obviously I'm missing something; Thanks, Graham From: David Bevan david.be...@pb.com To: GRAHAM ASHER graham.as...@btinternet.com Sent: Tuesday, 31 August, 2010 16:20:08 Subject: RE: [ft-devel] a satisfactory fix for the cubic spline bug From:GRAHAM ASHER [mailto:graham.as...@btinternet.com] Sent: 31 August 2010 15:56 To: David Bevan Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug Midpoint as defined by bisection is the point you get when you split a cubic spline into two by the bisection method (as used by FreeType in gray_split_cubic). It is defined as the midpoint of the line between the two midpoints of the lines between the three midpoints of the lines between the four control points, taken in order. It is of course a point on the curve. So that’s the point t = 0.5 in the parametric equation — found using de Casteljau’s algorithm. Your example gives a midpoint of (31.25, 20.625). Applying the midpoint method again (hastily) to the left-hand curve seems to yield a y coordinate of 21.84375, so if my arithmetic is correct your example is a good one. Using the equation in Hain’s paper (p.4; with v=0.1), the maximum deviation tmax in my example is at 0.3503928884, which is the point (16.26529900, 23.37564709). David %^ Thanks, Graham From:David Bevan david.be...@pb.com To: GRAHAM ASHER graham.as...@btinternet.com Sent: Tuesday, 31 August, 2010 15:20:59 Subject: RE: [ft-devel] a satisfactory fix for the cubic spline bug From:GRAHAM ASHER [mailto:graham.as...@btinternet.com] Sent: 31 August 2010 15:01 To: David Bevan; freetype-devel Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug David, (vi) Out of interest, please give an example, with coordinates, of a cubic spline with both control points on the same side of the straight line from start to end, for which the midpoint of the curve, as defined by bisection, is not the point of maximum deviation. I expect that something like the following would be an example: P0: 0,0 P1: 0,50 P2: 50,5 P3, 100,0 But to be sure I’d need to know what you mean by “midpoint as defined by bisection”? Is it t = 0.5 in the parametric equation, the point perpendicular to the midpoint of the chord, or something else? David %^___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] preliminary analysis of the problem with cubic spline optimisation
The aim is to draw a straight line between the start end end of a cubic spline, instead of rendering the curve correctly, if the curve deviates by less than a certain value from the straight line. The code in gray_render_cubic in ftgrays.c checks only the midpoint of the curve. However, this is not necessarily the furthest point from the straight line. If the sequence start, control1, control2, end is not monotonic in one of the dimensions x, y, an s-shaped curve is produced with points further from the line than the midpoint, which may even lie on the line. This situation occurs in 's' for the sample font. With this information I can easily produce a fix, simply by testing for non-monotonicity and disabling the optimisation in such circumstances, but I shall see if I can up with something slightly better. Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: preliminary analysis of the problem with cubic spline optimisation
Correction: it's not monotonicity that matters, but having the two control points on different sides of the straight line. Graham Asher wrote: The aim is to draw a straight line between the start end end of a cubic spline, instead of rendering the curve correctly, if the curve deviates by less than a certain value from the straight line. The code in gray_render_cubic in ftgrays.c checks only the midpoint of the curve. However, this is not necessarily the furthest point from the straight line. If the sequence start, control1, control2, end is not monotonic in one of the dimensions x, y, an s-shaped curve is produced with points further from the line than the midpoint, which may even lie on the line. This situation occurs in 's' for the sample font. With this information I can easily produce a fix, simply by testing for non-monotonicity and disabling the optimisation in such circumstances, but I shall see if I can up with something slightly better. Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] tentative fix for cubic spline bug
Here's a fix that works. I'm trying to think of a faster way of doing
it. The fix splits the cubic spline in two, guaranteeing that the
resulting curves have their control points on the same side of the
straight lines from start to end, then performs the original test for
the distance (or rather maximum difference of x or y coord) of the curve
midpoints from the straight lines. Below is a modified version of the
start of gray_render_cubic. Suggestions for better fixes cheerfully
welcomed. At least we now know what the problem is.
Graham
-
static int
gray_render_cubic( RAS_ARG_ FT_Vector* control1,
FT_Vector* control2,
FT_Vector* to )
{
int top, level;
int*levels;
FT_Vector* arc;
int error = 0;
/*
Split the cubic into two, creating 7 points,
then find the midpoints of the first and second curves.
Find how far they are from the straight lines joining
the start and end of the two curves. If they are close enough
we can draw them as straight lines.
*/
int x0, x1, x2, x3, x4, x5, x6, midx0, midx1;
int y0, y1, y2, y3, y4, y5, y6, midy0, midy1;
TPos dx0, dx1, dy0, dy1;
x0 = DOWNSCALE(ras.x);
x6 = to-x;
x1 = (x0 + control1-x) / 2;
x3 = (control1-x + control2-x) / 2;
x5 = (control2-x + x6) / 2;
x2 = (x1 + x3) / 2;
x4 = (x3 + x5) / 2;
x3 = (x2 + x4) / 2;
midx0 = (x0 + x3 + 3 * (x1 + x2)) / 8;
midx1 = (x3 + x6 + 3 * (x4 + x5)) / 8;
dx0 = x0 + x3 - (midx0 1); if (dx0 0) dx0 = -dx0;
dx1 = x3 + x6 - (midx1 1); if (dx1 0) dx1 = -dx1;
y0 = DOWNSCALE(ras.y);
y6 = to-y;
y1 = (y0 + control1-y) / 2;
y3 = (control1-y + control2-y) / 2;
y5 = (control2-y + y6) / 2;
y2 = (y1 + y3) / 2;
y4 = (y3 + y5) / 2;
y3 = (y2 + y4) / 2;
midy0 = (y0 + y3 + 3 * (y1 + y2)) / 8;
midy1 = (y3 + y6 + 3 * (y4 + y5)) / 8;
dy0 = y0 + y3 - (midy0 1); if (dy0 0) dy0 = -dy0;
dy1 = y3 + y6 - (midy1 1); if (dy1 0) dy1 = -dy1;
if (dx0 dx1)
dx0 = dx1;
if (dx0 dy0)
dx0 = dy0;
if (dx0 dy1)
dx0 = dy1;
level = 1;
dx0 /= ras.cubic_level;
while ( dx0 0 )
{
dx0 = 2;
level++;
}
if ( level = 1 )
{
TPos to_x, to_y;
to_x = UPSCALE( to-x );
to_y = UPSCALE( to-y );
/* Recalculation of midpoint is needed only if UPSCALE and DOWNSCALE
have any effect. */
#if (PIXEL_BITS != 6)
x3 = ( ras.x + to_x +
3 * UPSCALE( control1-x + control2-x ) ) / 8;
y3 = ( ras.y + to_y +
3 * UPSCALE( control1-y + control2-y ) ) / 8;
#endif
error = gray_render_line( RAS_VAR_ x3, y3 );
if (!error)
error = gray_render_line( RAS_VAR_ to_x, to_y );
return error;
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: preliminary analysis of the problem with cubic spline optimisation
It can happen, though. In fact I now don't think it can happen. If there are any good mathematicians out there (better than me at this, which sets quite a low bar), please confirm that no point on a cubic spline curve with both control points on the same side of the straight line from start to end can be further from the line than the curve's midpoint as defined by bisection of the curve. Graham Graham Asher wrote: No, in nearly all cases the midpoint is the point on the curve furthest from the straight line when both control points are on the same side. It can happen, though. I'm now working on a fix depending on finding how far the furthest control point is from the straight line. No point on the curve can be further from the straight line than both control points. Graham James Cloos wrote: GA == Graham Asher graham.as...@btinternet.com writes: GA Correction: it's not monotonicity that matters, but having the two GA control points on different sides of the straight line. Wouldn't the midpoint also fail to be the furthest point from the line whenever the two off-curve control points are on the same side of the midpoint? -JimC ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: render error after ftgrays: Speed up rendering of small cubic splines.
Thanks for that. I'll have a look at it when I have time - probably at the weekend. I must say though that I did not make this checkin. Although the change is due to a suggestion of mine, someone else made the change and 'kindly' attributed it to me. Can you supply the font file too? I assume it's an Adobe Type 1 file or something like that. Graham - Original Message From: kde...@vogtner.de kde...@vogtner.de To: Graham Asher graham.as...@btinternet.com Sent: Tuesday, 24 August, 2010 14:02:34 Subject: render error after ftgrays: Speed up rendering of small cubic splines. Graham, please find enclosed a test case (pdf) which includes the font and a screen shot. git bisect said: /tmp/unter/freetype2 git bisect bad 7fb3ef64a24489189113f693696eaf935f500c3f is first bad commit commit 7fb3ef64a24489189113f693696eaf935f500c3f Author: Graham Asher graham.as...@btinternet.com Date: Thu Jun 10 08:10:57 2010 +0200 ftgrays: Speed up rendering of small cubic splines. * src/smooth/ftgrays.c (gray_render_cubic): Implement new, simplified algorithm to find out whether the spline can be replaced with two straight lines. See this thread for more: http://lists.gnu.org/archive/html/freetype-devel/2010-06/msg0.html :100644 100644 183237f08775ddd8e69134f992717f3a9e920f5c 83211cfb85702072ebb3d14b7d10be2cd1259aa2 M ChangeLog :04 04 13cdcced61359f0d3f72e75580006b7e824535e9 a3d9ee83023ed6fca1ad26f2e76e7577756f2212 M src Regards Stefan ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] rasterization without sorting - in defence of my approach
The current FreeType approach is definitely inefficient for some shapes. For example, imagine an almost horizontal stroke N pixels wide, which has a top edge starting at pixel T + 1 and ending at pixel T. (Such strokes occur frequently in Chinese ideographs.) This contour (the top edge) will generate N cells, all with a Y coordinate of T, and with X coordinates 0...N - 1, which will be inserted into the linked list for row T. The cells will be inserted in the worst possible order (reverse order), requiring (N^2) / 2 comparisons to find the correct place in the list. If the stroke is 128 pixels wide - which can easily happen when drawing large glyphs, or using high resolution for printing - there are thus 8192 comparisons when sorting this line of cells. My method (direct insertion into a sparse array) is almost certainly better when there is enough memory to create an array with a slot for every pixel in the bitmap, but if not, it falls back on quicksort. So is the quicksort method always better? Unfortunately not. Quicksort is very slow when working on almost-sorted sequences, and that is the type of sequence generated by FreeType. We can probably improve matters by randomising the sequence before sorting. I haven't tried that method for FreeType, but it has worked dramatically well for me in other cases. In conclusion, more benchmarking is needed to decide on an optimal approach, balanced for the average mix of cases. I am also aware that FreeType's sole purpose is to rasterize glyphs, while mine is also to rasterize large arbitrary shapes. Nevertheless, these aims tend to converge as display resolution improves; at modern resolutions of around 200dpi, 18pt glyphs are as large as 50 x 50 pixels. Graham Asher CartoType Ltd. - Original Message From: GRAHAM ASHER graham.as...@btinternet.com To: Werner LEMBERG w...@gnu.org Cc: FreeType freetype-devel@nongnu.org Sent: Wednesday, 21 July, 2010 10:20:54 Subject: Re: [ft-devel] Re: rasterization without sorting Werner, I've just taken a look at the latest version of ftgrays.c in git, and to my surprise, it already uses a design which I considered and rejected! I am not claiming that I was right in rejecting it, though. It avoids using quicksort by creating a list of cells for each scan line (i.e., for each y coordinate), then inserting each new cell in a singly linked list. Thus sorting on the major key is avoided, but there is still an insertion sort on the minor key. I rejected this design because the aim was to avoid all sorting, and I believed that an O(n^2) sort for each scan line would be inefficient for complicated shapes, where many contours cross the scan lines. However, I may be wrong, and I assume that somebody (David, probably) benchmarked and compared various approaches before choosing this one. My design is still available if anyone wants it, but it looks as though it is not needed. Best regards, Graham - Original Message From: Werner LEMBERG w...@gnu.org To: graham.as...@btinternet.com Cc: freetype-devel@nongnu.org Sent: Tuesday, 20 July, 2010 13:28:50 Subject: Re: [ft-devel] Re: rasterization without sorting Panic over. A small modification was needed to the criterion for skipping an empty cell. Both cover and area should be zero. I enclose new versions of the patch and complete file for ftgrays.c. This looks indeed very straightforward. However, your patch doesn't apply to the current version of FreeType's ftgrays.c in a non-trivial way. May I ask for an update? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: rasterization without sorting
Werner, I've just taken a look at the latest version of ftgrays.c in git, and to my surprise, it already uses a design which I considered and rejected! I am not claiming that I was right in rejecting it, though. It avoids using quicksort by creating a list of cells for each scan line (i.e., for each y coordinate), then inserting each new cell in a singly linked list. Thus sorting on the major key is avoided, but there is still an insertion sort on the minor key. I rejected this design because the aim was to avoid all sorting, and I believed that an O(n^2) sort for each scan line would be inefficient for complicated shapes, where many contours cross the scan lines. However, I may be wrong, and I assume that somebody (David, probably) benchmarked and compared various approaches before choosing this one. My design is still available if anyone wants it, but it looks as though it is not needed. Best regards, Graham - Original Message From: Werner LEMBERG w...@gnu.org To: graham.as...@btinternet.com Cc: freetype-devel@nongnu.org Sent: Tuesday, 20 July, 2010 13:28:50 Subject: Re: [ft-devel] Re: rasterization without sorting Panic over. A small modification was needed to the criterion for skipping an empty cell. Both cover and area should be zero. I enclose new versions of the patch and complete file for ftgrays.c. This looks indeed very straightforward. However, your patch doesn't apply to the current version of FreeType's ftgrays.c in a non-trivial way. May I ask for an update? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] rasterization without sorting
I think using #ifdefs is a good idea for the moment. Also, there are two semi-obvious ways to make the optimisation even better, and I want to try to implement them: 1. Pre-calculate the width of the array, to avoid calculating it in every call to gray_record_cell. 2. (This is the big one). Use a variant of the TCell structure without x and y fields, making it half the size; thus twice as many cells can be stored. X and y can be calculated from the array index inside the new version of gray_sweep. Graham - Original Message From: Werner LEMBERG w...@gnu.org To: graham.as...@btinternet.com Cc: freetype-devel@nongnu.org Sent: Monday, 19 July, 2010 16:49:20 Subject: Re: [ft-devel] rasterization without sorting I have been working on a new way to optimise anti-aliased rasterization in FreeType and other similar libraries. Great! I am not completely certain that this is the best way to do things for *glyph* rasterization, because glyphs are special cases, being in general relatively small, but it speeds up CartoType by about 7%, and I believe will speed up FreeType. Given that David already tried to optimize the AA rasterization, an improvement of 7% is really impressive. I enclose a patch file based on my current version of ftgrays.c, which I think is very slightly different from the official version. I also enclose ftgrays.c itself, for clarity. The differences are very simple and affect only this one file. Thanks a lot! Will have a look the next days. What do you think about embedding your changes into #ifdef's temporarily so that anxious users could deactivate it if they are not in the mood of beta testing? :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: rasterization without sorting
I have just noticed that this doesn't work perfectly yet. I am sure the principle is sound, though. I'll send a revised version as soon as possible. - Original Message From: GRAHAM ASHER graham.as...@btinternet.com To: freetype-devel@nongnu.org Sent: Monday, 19 July, 2010 16:11:35 Subject: rasterization without sorting I have been working on a new way to optimise anti-aliased rasterization in FreeType and other similar libraries. This arises from my need to make CartoType, my map rendering library, run as fast as possible. It uses FreeType for glyph rendering, and FreeType's smooth rasterization algorithm for drawing polygons. Benchmarking showed that about half of all the time taken by rasterization of map shapes was taken by sorting the array of Cell objects (TRaster.cells). Sorting, even using quicksort, is not as fast as direct insertion by array index. I create array indexes using the x and y coordinates of the cell, then put the cell directly into its place. This leaves empty cells, and so requires a modified - but actually simpler - version of gray_sweep, and a change to the way gray_record_cell works. The algorithm, in pseudo-code, is this: if (clipped width in pixels + 1) * clipped height in pixels not greater than maximum number of cells zero the cells array when recording a cell, insert it at index (y * clipped width in pixels + 1) + x + 1, and add cover and area to existing values in the array at that index do NOT call gray_quick_sort use a new version of gray_sweep that skips empty cells (cover = 0) (and does not need to accumulate coverage and area for cells with the same coords) else do everything the old way I am not completely certain that this is the best way to do things for *glyph* rasterization, because glyphs are special cases, being in general relatively small, but it speeds up CartoType by about 7%, and I believe will speed up FreeType. I enclose a patch file based on my current version of ftgrays.c, which I think is very slightly different from the official version. I also enclose ftgrays.c itself, for clarity. The differences are very simple and affect only this one file. Graham Asher CartoType Ltd ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] testing of my patch should include Adobe Type 1 fonts
My patch affects cubic splines only. TrueType fonts do not use cubic splines, only quadratics, so any testing should include Adobe Type 1 fonts, which use cubics, and other PostScript font formats that use the same system for storing outlines. Does this font collection contain any such fonts? Graham Alexei Podtelezhnikov wrote: I tested Graham's patch stand alone on top of 2.3.12. No complaints here. The entire Fedora 12 font collection looks good. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
You're welcome - I see that you had to get rid of a check on the return value of gray_render_line, which I forgot about. That is there because I use a modified version of FreeType that can be compiled as pure .NET intermediate language code; and to do that I had to get rid of setjmp and longjmp; incidentally, with no performance penalty and little extra complexity. Best regards, Graham Werner LEMBERG wrote: here's what I think is a better version of the start of the function. [...] This is now in the git repository (with small fixes to make it compile). Thanks a lot! Please test. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem with ligatures and strikes
In your image, why are the ligatures anti-aliased, while the main text is not? Surely you should generate non-anti-aliased glyphs to go with the non-anti-aliased bitmaps stored in the font file; or, if anti-aliasing is desired, the stored bitmaps should not be used. In general, it should not matter if some bitmaps are missing from the set of stored bitmaps; they are (or should be) guaranteed to be the same as the bitmaps which would be generated from the outline and instructions in the font file. And that should include generated ligatures. Graham Behdad Esfahbod wrote: Hi, The Calibri font shipped in Windows XP has bitmap strikes for a variety of sizes, but from what I understand, no bitmap glyphs for many ligature combination it defines in its GSUB table, for example, for 'tt', 'ft', 'ffi' among others. That results in very ugly rendering (see attached). My question is, how does Windows deal with this? Do they turn certain features off if using strikes? Not form the ligature if not found in the current strike? I need help understanding this to implement the correct behavior since I don't have access to Windows. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
No, I don't think it's worth worrying about this right now. I worked on this because I wanted to create a version of my CartoType library as a portable .NET assembly, and in fact I managed to compile CartoType as C++/CLI code, which is a tribute to its robustness; but to do that I had to remove setjmp/longjmp and change a few symbols which conflicted with new keywords, like 'generic'. It was an interesting exercise, but proved to be a dead end (for the moment) because C++/CLI is not supported for Windows Mobile, and 'portable' .NET assemblies seem not in fact to be portable. Doing this showed that setjmp and longjmp are not necessary for FreeType; and perhaps they should be removed in future; but there's no compelling reason to do so right now. Graham Werner LEMBERG wrote: [...] I use a modified version of FreeType that can be compiled as pure .NET intermediate language code; and to do that I had to get rid of setjmp and longjmp; incidentally, with no performance penalty and little extra complexity. Is this something we should consider in general? I mean, are there benefits for removing setjmp/longjmp except portability to other programming languages? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
Unfortunately not only there but in the rasterizer, if memory serves. They were not in any place where I could get rid of them easily by disabling certain features. Graham Behdad Esfahbod wrote: On 06/10/2010 05:17 AM, Graham Asher wrote: Doing this showed that setjmp and longjmp are not necessary for FreeType; Indeed. They are only used for error-handling in the validator modules. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
Werner,
I think your patch is slightly wrong because you use the same values for
mid_x and mid_y for both the comparison and for drawing; however, one
set if values needs to go through DownScale() and the other through
UpScale(); that's why I calculate separately in my hastily-prepared
patch. I'll see if I can come up with something better.
Graham
Werner LEMBERG wrote:
Calculate the midpoint and compare it with start and end: [...]
For me, this looks good. Thanks for working on this.
I am sceptical about the need to calculate both da and db. Perhaps
db only will suffice. I hope that David or Werner can comment.
This is something Ken can probably check: He has a large database for
Ghostscript to compare rendering results, and artifacts introduced by
the simplified shorthand calculation would easily show up, I think.
Below is a patch according to your data (hopefully, I've understood
you correctly). Please check and test.
Werner
==
--- ftgrays.c.orig 2009-07-31 18:45:19.0 +0200
+++ ftgrays.c 2010-06-08 09:56:23.0 +0200
@@ -1007,45 +1007,40 @@
const FT_Vector* control2,
const FT_Vector* to )
{
-TPosdx, dy, da, db;
+TPosdx, dy;
+TPosmid_x, mid_y;
int top, level;
int*levels;
FT_Vector* arc;
-dx = DOWNSCALE( ras.x ) + to-x - ( control1-x 1 );
-if ( dx 0 )
- dx = -dx;
-dy = DOWNSCALE( ras.y ) + to-y - ( control1-y 1 );
-if ( dy 0 )
- dy = -dy;
-if ( dx dy )
- dx = dy;
-da = dx;
+/* Calculate midpoint and compare it with start and end. */
+mid_x = ( DOWNSCALE( ras.x ) + to-x +
+ 3 * ( control1-x + control2-x ) ) / 8;
+mid_y = ( DOWNSCALE( ras.y ) + to-y +
+ 3 * ( control1-y + control2-y ) ) / 8;
-dx = DOWNSCALE( ras.x ) + to-x - 3 * ( control1-x + control2-x );
+dx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
if ( dx 0 )
dx = -dx;
-dy = DOWNSCALE( ras.y ) + to-y - 3 * ( control1-x + control2-y );
+dy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
-db = dx;
+/* Check whether an approximation with straight lines is sufficient. */
level = 1;
-da= da / ras.cubic_level;
-db= db / ras.conic_level;
-while ( da 0 || db 0 )
+dx= dx / ras.conic_level;
+while ( dx 0 )
{
- da = 2;
- db = 3;
+ dx = 3;
level++;
}
if ( level = 1 )
{
- TPos to_x, to_y, mid_x, mid_y;
+ TPos to_x, to_y;
to_x = UPSCALE( to-x );
@@ -1104,7 +1099,7 @@
Draw:
{
-TPos to_x, to_y, mid_x, mid_y;
+TPos to_x, to_y;
to_x = arc[0].x;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
Another question arises: why do we divide by ras.conic_level when we are
dealing with cubic splines? Surely it should be
dx= dx / ras.cubic_level;
or (better - we can use assignment operators in FreeType, I think ;-):
dx/= ras.cubic_level;
Graham
Werner LEMBERG wrote:
Calculate the midpoint and compare it with start and end: [...]
For me, this looks good. Thanks for working on this.
I am sceptical about the need to calculate both da and db. Perhaps
db only will suffice. I hope that David or Werner can comment.
This is something Ken can probably check: He has a large database for
Ghostscript to compare rendering results, and artifacts introduced by
the simplified shorthand calculation would easily show up, I think.
Below is a patch according to your data (hopefully, I've understood
you correctly). Please check and test.
Werner
==
--- ftgrays.c.orig 2009-07-31 18:45:19.0 +0200
+++ ftgrays.c 2010-06-08 09:56:23.0 +0200
@@ -1007,45 +1007,40 @@
const FT_Vector* control2,
const FT_Vector* to )
{
-TPosdx, dy, da, db;
+TPosdx, dy;
+TPosmid_x, mid_y;
int top, level;
int*levels;
FT_Vector* arc;
-dx = DOWNSCALE( ras.x ) + to-x - ( control1-x 1 );
-if ( dx 0 )
- dx = -dx;
-dy = DOWNSCALE( ras.y ) + to-y - ( control1-y 1 );
-if ( dy 0 )
- dy = -dy;
-if ( dx dy )
- dx = dy;
-da = dx;
+/* Calculate midpoint and compare it with start and end. */
+mid_x = ( DOWNSCALE( ras.x ) + to-x +
+ 3 * ( control1-x + control2-x ) ) / 8;
+mid_y = ( DOWNSCALE( ras.y ) + to-y +
+ 3 * ( control1-y + control2-y ) ) / 8;
-dx = DOWNSCALE( ras.x ) + to-x - 3 * ( control1-x + control2-x );
+dx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
if ( dx 0 )
dx = -dx;
-dy = DOWNSCALE( ras.y ) + to-y - 3 * ( control1-x + control2-y );
+dy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
-db = dx;
+/* Check whether an approximation with straight lines is sufficient. */
level = 1;
-da= da / ras.cubic_level;
-db= db / ras.conic_level;
-while ( da 0 || db 0 )
+dx= dx / ras.conic_level;
+while ( dx 0 )
{
- da = 2;
- db = 3;
+ dx = 3;
level++;
}
if ( level = 1 )
{
- TPos to_x, to_y, mid_x, mid_y;
+ TPos to_x, to_y;
to_x = UPSCALE( to-x );
@@ -1104,7 +1099,7 @@
Draw:
{
-TPos to_x, to_y, mid_x, mid_y;
+TPos to_x, to_y;
to_x = arc[0].x;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
Werner,
here's what I think is a better version of the start of the function.
I've combined a few declarations and initialisations; probably against
your house style, so please adjust as appropriate if you don't like it.
Important changes: (i) dx is now divided by ras.cubic_level; (ii) mid_x
and mid_y are recalculated only if necessary.
Graham
static int
gray_render_cubic( RAS_ARG_ FT_Vector* control1,
FT_Vector* control2,
FT_Vector* to )
{
int top, level;
int*levels;
FT_Vector* arc;
int error = 0;
int mid_x = (DOWNSCALE( ras.x ) + to-x + 3 * (control1-x +
control2-x)) / 8;
int mid_y = (DOWNSCALE( ras.y ) + to-y + 3 * (control1-y +
control2-y)) / 8;
TPos dx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
TPos dy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
if ( dx 0 )
dx = -dx;
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
level = 1;
dx /= ras.cubic_level;
while ( dx 0 )
{
dx = 3;
level++;
}
if ( level = 1 )
{
TPos to_x, to_y;
to_x = UPSCALE( to-x );
to_y = UPSCALE( to-y );
/* Recalculation of midpoint is needed only if UPSCALE and DOWNSCALE
have any effect. */
#if (PIXEL_BITS != 6)
mid_x = ( ras.x + to_x +
3 * UPSCALE( control1-x + control2-x ) ) / 8;
mid_y = ( ras.y + to_y +
3 * UPSCALE( control1-y + control2-y ) ) / 8;
#endif
error = gray_render_line( RAS_VAR_ mid_x, mid_y );
if (!error)
error = gray_render_line( RAS_VAR_ to_x, to_y );
return error;
}
Werner LEMBERG wrote:
Calculate the midpoint and compare it with start and end: [...]
For me, this looks good. Thanks for working on this.
I am sceptical about the need to calculate both da and db. Perhaps
db only will suffice. I hope that David or Werner can comment.
This is something Ken can probably check: He has a large database for
Ghostscript to compare rendering results, and artifacts introduced by
the simplified shorthand calculation would easily show up, I think.
Below is a patch according to your data (hopefully, I've understood
you correctly). Please check and test.
Werner
==
--- ftgrays.c.orig 2009-07-31 18:45:19.0 +0200
+++ ftgrays.c 2010-06-08 09:56:23.0 +0200
@@ -1007,45 +1007,40 @@
const FT_Vector* control2,
const FT_Vector* to )
{
-TPosdx, dy, da, db;
+TPosdx, dy;
+TPosmid_x, mid_y;
int top, level;
int*levels;
FT_Vector* arc;
-dx = DOWNSCALE( ras.x ) + to-x - ( control1-x 1 );
-if ( dx 0 )
- dx = -dx;
-dy = DOWNSCALE( ras.y ) + to-y - ( control1-y 1 );
-if ( dy 0 )
- dy = -dy;
-if ( dx dy )
- dx = dy;
-da = dx;
+/* Calculate midpoint and compare it with start and end. */
+mid_x = ( DOWNSCALE( ras.x ) + to-x +
+ 3 * ( control1-x + control2-x ) ) / 8;
+mid_y = ( DOWNSCALE( ras.y ) + to-y +
+ 3 * ( control1-y + control2-y ) ) / 8;
-dx = DOWNSCALE( ras.x ) + to-x - 3 * ( control1-x + control2-x );
+dx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
if ( dx 0 )
dx = -dx;
-dy = DOWNSCALE( ras.y ) + to-y - 3 * ( control1-x + control2-y );
+dy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
-db = dx;
+/* Check whether an approximation with straight lines is sufficient. */
level = 1;
-da= da / ras.cubic_level;
-db= db / ras.conic_level;
-while ( da 0 || db 0 )
+dx= dx / ras.conic_level;
+while ( dx 0 )
{
- da = 2;
- db = 3;
+ dx = 3;
level++;
}
if ( level = 1 )
{
- TPos to_x, to_y, mid_x, mid_y;
+ TPos to_x, to_y;
to_x = UPSCALE( to-x );
@@ -1104,7 +1099,7 @@
Draw:
{
-TPos to_x, to_y, mid_x, mid_y;
+TPos to_x, to_y;
to_x = arc[0].x;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] possible inefficiency in gray_render_cubic
I have discovered a possible inefficiency in gray_render_cubic in
ftsmooth.c. Removing it (by means of what I admit is a hack based on a
limited understanding of the code) gives a vast speedup with no
apparent loss of quality. The error is an incorrect method of
calculating whether to use a short cut when all the points of a cubic
spline are close together. There is also an obvious typo (see 4A below)
in the current code. This is based on the current state of the code in
the Git repository.
Here's my analysis so far.
1. LOOP PASSES
The number of passes through the main loop is controlled largely by the
variable 'level'. Reducing that number increases the speed of the
function. If 'level' is no greater than one there are no passes through
the loop. Instead, there's a short cut that draws a straight line from
the start to the mid point of the curve and another from the mid point
to the end.
2. MEANING OF 'level'
It's evident from the nature of the short-cut code that 'level' is
related to the maximum distance between the start, end and control
points. If all the points are very close together, there is no point in
generating a full curve, especially as the units used are normally
64ths of pixels; it's not very meaningful to create a curve inside a
pixel, and probably won't affect its grey level, as compared with a
straight line. Thus 'level' ought to be 0 or 1 if the points are very
close together.
3. EXAMPLE
This example is taken from my CartoType map rendering code.
Coordinates: start = 16272, 24478, control1 = 16276, 24461, control2 =
16266, 24443, end = 16249, 24439
Calculated value of da after 'da = dx': 31
Calculated value of db after 'db = dx': 97795
Calculated value of 'level' (with ras.cubic_level == 64 and
ras.conic_level = 128): 5.
Passes through the main loop: 16.
4. ANOMALOUS VALUE OF 'db'
Let's look at the value of 'db' again: 97795. This large value comes
from the code
dx = DOWNSCALE( ras.x ) + to-x - 3 * ( control1-x + control2-x );
if ( dx 0 )
dx = -dx;
dy = DOWNSCALE( ras.y ) + to-y - 3 * ( control1-x + control2-y );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
db = dx;
which is where I think the problem is. The idea seems to be to get the
maximum distance of the midpoint from the start and end points, but the
calculation is wrong: it adds two values (the start and end
coordinates) then subtracts six coordinates (the control points,
multiplied by three). Thus, if all 4 coordinates (x or y) are
identical, the answer is 2x - 6x, or -4x. In our case we get a value
for 'db' of ~100,000 because that is 4 times the y coordinate value;
they are all ~25000.
(4A. AN OBVIOUS BUG: the code 'control1-x
+ control2-y' above should obviously be 'control1-y
+ control2-y'. That needs to be fixed if my suggestions here
are rejected.)
5. A SIMPLE HACK
My initial fix was to simply remove the multiplication by 3, which was
probably cut and pasted from the later correct calculation of the
curve's midpoint. Thus we have:
dx = DOWNSCALE( ras.x ) + to-x - ( control1-x + control2-x );
if ( dx 0 )
dx = -dx;
dy = DOWNSCALE( ras.y ) + to-y - ( control1-y + control2-y );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
db = dx;
which, as mentioned above, seems to fix the trouble, without apparent
bad consequences.
6. A POSSIBLE BETTER FIX
Calculate the midpoint and compare it with start and end:
{
int mid_x = (DOWNSCALE( ras.x ) + to-x + 3 * (control1-x + control2-x)) / 8;
int mid_y = (DOWNSCALE( ras.y ) + to-y + 3 * (control1-y + control2-y)) / 8;
dx = DOWNSCALE( ras.x ) + to-x - 3 * ( mid_x 1 );
if ( dx 0 )
dx = -dx;
dy = DOWNSCALE( ras.y ) + to-y - 3 * ( mid_y 1 );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
db = dx;
}
7. FURTHER WORK: WHY DO WE NEED da AND db?
I am sceptical about the need to calculate both da and db. Perhaps db
only will suffice. I hope that David or Werner can comment.
Best regards,
Graham Asher
CartoType Ltd
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: possible inefficiency in gray_render_cubic
Correction (sorry, but this stuff gets confusing). Section 6 should
read:
6. A POSSIBLE BETTER FIX
Calculate the midpoint and compare it with start and end:
{
int mid_x = (DOWNSCALE( ras.x ) + to-x + 3 * (control1-x + control2-x)) / 8;
int mid_y = (DOWNSCALE( ras.y ) + to-y + 3 * (control1-y + control2-y)) / 8;
dx = DOWNSCALE( ras.x ) + to-x - ( mid_x 1 );
if ( dx 0 )
dx = -dx;
dy = DOWNSCALE( ras.y ) + to-y - ( mid_y 1 );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
db = dx;
}
without those multiplications by 3, which crept in again.
Graham
Graham Asher wrote:
I
have discovered a possible inefficiency in gray_render_cubic in
ftsmooth.c. Removing it (by means of what I admit is a hack based on a
limited understanding of the code) gives a vast speedup with no
apparent loss of quality. The error is an incorrect method of
calculating whether to use a short cut when all the points of a cubic
spline are close together. There is also an obvious typo (see 4A below)
in the current code. This is based on the current state of the code in
the Git repository.
Here's my analysis so far.
1. LOOP PASSES
The number of passes through the main loop is controlled largely by the
variable 'level'. Reducing that number increases the speed of the
function. If 'level' is no greater than one there are no passes through
the loop. Instead, there's a short cut that draws a straight line from
the start to the mid point of the curve and another from the mid point
to the end.
2. MEANING OF 'level'
It's evident from the nature of the short-cut code that 'level' is
related to the maximum distance between the start, end and control
points. If all the points are very close together, there is no point in
generating a full curve, especially as the units used are normally
64ths of pixels; it's not very meaningful to create a curve inside a
pixel, and probably won't affect its grey level, as compared with a
straight line. Thus 'level' ought to be 0 or 1 if the points are very
close together.
3. EXAMPLE
This example is taken from my CartoType map rendering code.
Coordinates: start = 16272, 24478, control1 = 16276, 24461, control2 =
16266, 24443, end = 16249, 24439
Calculated value of da after 'da = dx': 31
Calculated value of db after 'db = dx': 97795
Calculated value of 'level' (with ras.cubic_level == 64 and
ras.conic_level = 128): 5.
Passes through the main loop: 16.
4. ANOMALOUS VALUE OF 'db'
Let's look at the value of 'db' again: 97795. This large value comes
from the code
dx = DOWNSCALE( ras.x ) + to-x - 3 * ( control1-x + control2-x );
if ( dx 0 )
dx = -dx;
dy = DOWNSCALE( ras.y ) + to-y - 3 * ( control1-x + control2-y );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
db = dx;
which is where I think the problem is. The idea seems to be to get the
maximum distance of the midpoint from the start and end points, but the
calculation is wrong: it adds two values (the start and end
coordinates) then subtracts six coordinates (the control points,
multiplied by three). Thus, if all 4 coordinates (x or y) are
identical, the answer is 2x - 6x, or -4x. In our case we get a value
for 'db' of ~100,000 because that is 4 times the y coordinate value;
they are all ~25000.
(4A. AN OBVIOUS BUG: the code 'control1-x
+ control2-y' above should obviously be 'control1-y
+ control2-y'. That needs to be fixed if my suggestions here
are rejected.)
5. A SIMPLE HACK
My initial fix was to simply remove the multiplication by 3, which was
probably cut and pasted from the later correct calculation of the
curve's midpoint. Thus we have:
dx = DOWNSCALE( ras.x ) + to-x - ( control1-x + control2-x );
if ( dx 0 )
dx = -dx;
dy = DOWNSCALE( ras.y ) + to-y - ( control1-y + control2-y );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
db = dx;
which, as mentioned above, seems to fix the trouble, without apparent
bad consequences.
6. A POSSIBLE BETTER FIX
Calculate the midpoint and compare it with start and end:
{
int mid_x = (DOWNSCALE( ras.x ) + to-x + 3 * (control1-x + control2-x)) / 8;
int mid_y = (DOWNSCALE( ras.y ) + to-y + 3 * (control1-y + control2-y)) / 8;
dx = DOWNSCALE( ras.x ) + to-x - 3 * ( mid_x 1 );
if ( dx 0 )
dx = -dx;
dy = DOWNSCALE( ras.y ) + to-y - 3 * ( mid_y 1 );
if ( dy 0 )
dy = -dy;
if ( dx dy )
dx = dy;
db = dx;
}
7. FURTHER WORK: WHY DO WE NEED da AND db?
I am sceptical about the need to calculate both da and db. Perhaps db
only will suffice. I hope that David or Werner can comment.
Best regards,
Graham Asher
CartoType Ltd
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] unused variable in af_glyph_hints_reload
A finicky compiler told me that the variable AF_Point first in af_glyph_hints_reload in afhints.c was unnecessary. This turns out to be true (but note that there are two separate variables of this name in the function: we're talking about the first 'first'). It is assigned to at line 526: first = point + 1; but never used, so both the declaration and the assignment can be removed. Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] af_glyph_hints_compute_inflections can be removed
Here's a suggestion to simplify FreeType slightly by removing unused code. It has the agreeable side effect of preventing a compiler warning about an unused argument (get_inflections in af_glyph_hints_reload). 1. Remove the function af_glyph_hints_compute_inflections from afhints.c. 2. Remove the argument get_inflections from af_glyph_hints_reload, and remove the use of it inside that function. 3. Remove all uses of the third argument in calls to af_glyph_hints_reload. Best regards, Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] my Symbian OS glyph caching system
Some caveats about my glyph caching system: here is most of the text of my reply to Srinavasa: You are welcome to look at my cache implementation: it should be somewhere in this folder: http://developer.symbian.org/oss/FCL/sf/os/textandloc/file/030b3432fbe0/fontservices/fontstore However: 1. I can't provide support. I wrote this over 10 years ago. Since then many other people have worked on it and I no longer know exactly how it works. 2. As originally designed, the glyph cache was a binary tree that grew to a certain maximum size, after which no more entries could be added. For reasons of performance in a multi-processing system, glyphs could only be added, not deleted, addition of a glyph to a tree being an atomic action requiring no mutex. This design restriction may not exist any more; I don't know and don't have the time to find out. 3. Therefore you may be better advised, in a single-processing system, to create your own LRU glyph caching system. In principle it's simple (and I have used a variant of this design for my proprietary CartoType map rendering library): create a suitable database structure that stores key-value pairs where the key is the unique style of the glyph (font family, size, transform, emboldening, etc.) and the value is the glyph. Keep track of the least recently used glyph using a linked list; or simply rely on hashing, and remove glyphs where a conflict occurs. Best regards, Graham Asher Werner LEMBERG wrote: We are trying to achieve performance improvement either through parallelization/optimization in the freetype-2.3.11 library. Any help in this regard is highly appreciated. The solution is caching everything! Due to the nature of fonts I don't see much gain in parallelization while processing a single font. Graham Asher mentioned in a previous post that his FreeType caching stuff from the symbian OS is now open-source, so you might use this as a starting point. http://lists.gnu.org/archive/html/freetype-devel/2010-02/msg00033.html If you can optimize FreeType further (for example, using a profiler to isolate hot spots, then rewriting the code to make it faster) this is very welcomed. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] loading fonts with signature 'OTTO'
Thanks for the help, guys. Yes, it does work after all. Being assured that fonts of this type are supported made me keep trying, and I discovered that the problem was trivial: I had disabled loading of the psnames module, by commenting out FT_CONFIG_OPTION_POSTSCRIPT_NAMES. Although there's a debug-only message saying you need that module to load CFF fonts, the actual error code implies that the format is unrecognised, causing some confusion. What we need somewhere on the FreeType web site is a list of font formats and the modules needed to load them; together with any gotchas like this one (it's a gotcha because you have to enable the psnames module both in ft_module.h and by having the right config option macro defined). Graham James Cloos wrote: Graham == Graham Asher graham.as...@btinternet.com writes: Graham What we have here is a CFF font packaged inside something else, Graham I think. Yes, CFF inside a SFNT container; what the public know as otf fonts. When Werner added docs/formats.txt in 2004, ft already supported OTTO, and that was between 2.1.8 and 2.1.9. It is possible that the font is CID-encoded and that might explain why you are having difficulties with it. Other the freetype, you might want to see what the otfinfo(1) tool in http://www.lcdf.org/type/lcdf-typetools-2.82.tar.gz has to say about it. -JimC ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] loading fonts with signature 'OTTO'
Does anyone know whether FreeType supports fonts with the signature (first 4 bytes) 'OTTO', and if so, which drivers are needed, and in which version was support added for this format? I have googled for some time, and experimented with various drivers, but without success, so forgive me for asking: the answer isn't obvious to me. Thanks in advance, Graham Asher ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] loading fonts with signature 'OTTO'
Thanks - can you tell me which version this support was introduced in? I am using FreeType 2.3.7, and it doesn't work even though I have enabled and built the relevant drivers. Graham Tor Andersson wrote: On Fri, Mar 5, 2010 at 2:40 PM, Graham Asher graham.as...@btinternet.com wrote: Does anyone know whether FreeType supports fonts with the signature (first 4 bytes) 'OTTO', and if so, which drivers are needed, and in which version was support added for this format? I have googled for some time, and experimented with various drivers, but without success, so forgive me for asking: the answer isn't obvious to me. Thanks in advance, FreeType2 has supported OpenType fonts with CFF outlines for a long time (several years now) without needing to do anything special. You'll need to compile it with both the TrueType and CFF PostScript font drivers. The default configuration works well for me in MuPDF. -Tor ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] loading fonts with signature 'OTTO'
Thanks - I'll experiment further. But the addition of the CFF driver is not sufficient. What we have here is a CFF font packaged inside something else, I think. Graham James Cloos wrote: Graham == Graham Asher graham.as...@btinternet.com writes: Graham Thanks - can you tell me which version this support was Graham introduced in? I am using FreeType 2.3.7, and it doesn't work Graham even though I have enabled and built the relevant drivers. Git shows that the cff driver was added in 2000, back in the 2.0 timeframe. Certainly everything since 2.1.0 should work. -JimC ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype.com
Despicable domain squatting and negative advertising. Shame on them. Graham Behdad Esfahbod wrote: Stumbled upon freetype.com by accident. Have people seen this before? Interesting... behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Question about CFF arithmetic operator dup
The net effect of consuming one element and adding two is to add one. The code looks correct to me. Graham Asher Ning Dong wrote: Hi, I'm checking the cff_decoder_parse_charstrings function in cffgload.c of FT239. According to CFF technical note #5177, operator dup should consume one element and put two elements to arguement stack: dup any dup(12 27) any any But in cff_decoder_parse_charstrings, the codes like this: case cff_op_dup: FT_TRACE4(( dup\n )); args[1] = args[0]; args++;//should be args+=2? break; Only one element put to arguement stack. Is this a bug? FT2310 is the same. 2009-10-09 Ning Dong ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
I agree - I also have had no problem using custom allocators with FreeType 2. I have successfully used DlMalloc, and currently use a hybrid system comprising a fast-access pool of small blocks and a fallback to standard malloc and free. Graham Asher CartoType Mickey Gabel wrote: Werner LEMBERG wrote: both FT_New_Memory, and FT_New_Library (functions called within FT_Init_FreeType) are allocating memory, before I have a chance of setting the function pointers in FT_Memory.. To get around that I added an extra argument to the FT_Init_FreeType, which allows me to provide an FT_Memory structure, before any other freetype code is running. The `canonical' way is to replace ftsystem.c with something more appropriate for your target platform. For example, you can copy the whole file, only replacing `FT_New_Memory' to fit your needs. I don't see an immediate need to add new API functions -- you have to convince me that the just outlined method doesn't work :-) Sure I could do that... but then what is the point of having the FT_Memory struct...it doesn't work as advertised, and in order to fix it you advise me to replace a file where I need to implement my own ft_alloc methods? Well, advise... What I do is rather like taking a stab in the dark based on previous information :-) We have had no problem using FT2 with our own allocators (we work on systems were malloc() and free(), and possibly dynamic allocation entirely, are not present) So either I am doing it wrong, or Tom van Dick is doing it wrong. Here's what I do: 1) We have our own struct that contains both the ft library and an FT_Memory object. 2) We initialize the fields in the FT_Memory object so that our callbacks are called. 3) We call FT_New_Library and tell it to use our memory object. This is the first FT2 API call. // Initialize freetype2 lib-ft_memory.alloc= sf_FTalloc; lib-ft_memory.free= sf_FTfree; lib-ft_memory.realloc= sf_FTrealloc; lib-ft_memory.user= lib; ft_err = FT_New_Library( lib-ft_memory, lib-ft_lib ); I've always felt that this is the way it's meant to be used! It doesn't look like a hack, and everything is documented. Also it works :) Basically, if I understand correctly, what Tom asked is already there. There's no need to modify ft_system.c, or invent new API calls. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Switching to Git ?
From a purely personal point of view I welcome a move to git, simply to give me an incentive to learn git :-) Graham -Original Message- From: freetype-devel-bounces+graham.asher=btinternet@nongnu.org [mailto:freetype-devel-bounces+graham.asher=btinternet@nongnu.org] On Behalf Of Werner LEMBERG Sent: 23 February 2009 18:26 To: da...@freetype.org Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] Switching to Git ? long time no see :-) Glad that you are still alive. I'd like to know if Werner and others are interested in switching the FreeType repository to git in the near future ? Yes. I will do a new release soon (there are very embarrasing errors w.r.t. FT_Get_Advance which I'l fixing right now), then such a switch would be nice. We've discussed conversion to git earlier; you might look up the devel archive for details. I'm currently maintaining my own git repo with git-cvsimport, which works pretty well, but would like the ability to directly talk to the main server that way. Well, a direct import is trivial; however, it would be beneficial to walk over, say, the last 1000 to 2000 commits so that all get a nice one-line title. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Incremental font support
I'm sorry to say that there is no chance that I shall work on this again. I have too much on my plate for the foreseeable future. But I claim (as always ;-) that the parts of the bridge code I wrote are relatively easy to follow and can probably be debugged by single-stepping and thinking hard. Best regards, Graham -Original Message- From: freetype-devel-bounces+graham.asher=btinternet@nongnu.org [mailto:freetype-devel-bounces+graham.asher=btinternet@nongnu.org] On Behalf Of Werner LEMBERG Sent: 18 February 2009 06:51 To: gi...@ghostscript.com Cc: ray.johns...@artifex.com; henry.sti...@artifex.com; freetype-devel@nongnu.org Subject: Re: [ft-devel] Incremental font support We've been trying to resurrect the freetype bridge code in ghostscript, and have been testing against the freetype 2.3.8 release. I think there may be some bit rot in the incremental font support. Indeed. After Graham has stopped to work on this, noone has maintained this code; from time to time we've checked that compilation doesn't fail, but it hasn't been verified that it really works. In particular, at t1gload.c:287 T1_Load_Glyph() throws T1_Err_Invalid_Argument if the requested glyph index is larger than num_glyphs in the face. Yet as far as I can tell this was never set through the incremental font api. Similarly, version 1.205 of ttgload.c broke incremental truetype handling. To help in debugging it would be great if you can provide a small stand-alone snippet which I can compile easily, together with small input data if necessary. What can we do to fix this up? Is our code wrong? How is this supposed to work. I rather suspect that a bug has crept into FreeType. Do you have any tests for the incremental api? No, unfortunately. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: 答复: [ft-devel] porting the freetyp e tosymbian S60 3Rd
Oh dear - I shouldn't have said anything - sorry, I have no time to deal
with this. All I can say is that if there was a memory leak in FreeType it
would show up in all sorts of places - not just in Symbian OS. I suspect
it's a problem in the calling code.
I recently had heap corruption problems, added huge amounts of
instrumentation to the app I was working on, and found nothing wrong in
FreeType. The bug turned out to be in my own code, as usual.
Graham
-Original Message-
From: freetype-devel-bounces+graham.asher=btinternet@nongnu.org
[mailto:freetype-devel-bounces+graham.asher=btinternet@nongnu.org] On
Behalf Of Werner LEMBERG
Sent: 16 December 2008 17:54
To: hie...@hotmail.com
Cc: freetype-devel@nongnu.org
Subject: Re: 答复: [ft-devel] porting the freetype tosymbian S60 3Rd
Src/base/ftsystem.c
FT_CALLBACK_DEF( void* )
ft_alloc( FT_Memory memory,
long size )
{
FT_UNUSED( memory );
return ft_smalloc( size );// memory leak
}
You can have a look at the attached jepg for more information.
Thanks. I've forwarded your message to Graham since he has most
experience with Symbian.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Force PMingLiU like font do HINTING
Actually here is a better design: at the point of discovery, set a flag in the FT_Face structure. That way, there is no interference between a non-zero error code and the opportunity for the caller to ignore the problem. Graham -Original Message- From: Werner LEMBERG [mailto:[EMAIL PROTECTED] Sent: 04 December 2008 10:21 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; freetype-devel@nongnu.org Subject: Re: [ft-devel] Force PMingLiU like font do HINTING FreeType can't normally 'emit warning messages' because it is a library, not an app - it's up to the caller how to deal with errors. A new, well documented, error code that the caller can choose to ignore is the way to go, in my opinion. Sounds good. However, which function should return it? Or shall we add a new API function? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] missing out-of-memory check when creating family name for TrueType fonts
Here's another problem caused by a missing out-of-memory check. The function tt_face_get_name in sfobjs.c is defined as returning NULL if no name is present, but also returns NULL if the name is in fact present but there is no memory to allocate a copy of the name. This ambiguity leads to FT_Open_Face and associated functions seeming to succeed when in fact the face has not been constructed correctly. The correct fix would be for tt_face_get_name and similar functions to return an error code as well as the face pointer. For the moment I have no time to work out the correct set of patches, but I'll just put this on record as a warning. Callers should check whether face-family_name is null before using it; a missing family name is likely to be an error although the API doesn't actually tell us whether it is. Graham Asher ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_New_GlyphSlot crashes if out of memory allocating slot-internal
The title says it all really. I discovered this when by forcing random heap
allocation failures - a technique we used to use at Symbian.
If this line fails in ft_glyphslot_init
if ( FT_NEW( internal ) )
then slot-internal is null, and when FT_New_GlyphSlot detects the error and
calls ft_glyphslot_done, it calls ft_glyphslot_free_bitmap. which dies with
a null pointer access.
FT_BASE_DEF( void )
ft_glyphslot_free_bitmap( FT_GlyphSlot slot )
{
if ( slot-internal-flags FT_GLYPH_OWN_BITMAP ) // CRASH!
{
FT_Memory memory = FT_FACE_MEMORY( slot-face );
FT_FREE( slot-bitmap.buffer );
slot-internal-flags = ~FT_GLYPH_OWN_BITMAP;
}
else
{
/* assume that the bitmap buffer was stolen or not */
/* allocated from the heap */
slot-bitmap.buffer = NULL;
}
}
Suggested fix : change
if ( slot-internal-flags FT_GLYPH_OWN_BITMAP )
to
if (slot (slot-internal-flags FT_GLYPH_OWN_BITMAP) )
Best regards,
Graham Asher
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] missing 'const' on tt_post_default_names causes problems with writable static data
Here's another small problem I found when porting to 2.3.7. There's a missing 'const' in the declaration of the array tt_post_default_names. It causes the pointers to be non-const, and that creates 1032 (4 * 258) bytes of writable static data, which prevents builds from working for several platforms including Symbian OS. The fix is (line 67 of ttpost.c): static const FT_String* tt_post_default_names[258] = - static const FT_String* const tt_post_default_names[258] = Best regards, Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] discrepancy in underline offset
You're welcome - and I apologise for not noticing this when I moved to 2.3.7. Did you put some variant of my original explanatory comment in? It might help. Here it is: /* Adjust underline position from top edge to centre of stroke to convert TrueType meaning to FreeType meaning. */ Best regards, Graham -Original Message- From: Werner LEMBERG [mailto:[EMAIL PROTECTED] Sent: 12 October 2008 13:12 To: [EMAIL PROTECTED] Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] discrepancy in underline offset More than a year ago Graham wrote: root-underline_position = (FT_Short)(face-postscript.underlinePosition - (face-postscript.underlineThickness / 2)); Somehow this old email escaped my attention. I've now applied this fix to the sources so that the implementation follows the documentation. Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Re: meddlesome compiler warns against for( ...; ...; ...) ;
However, the logic is correct, is it not? It looks as if the code is checking whether all of the items in the array fulfil a condition. So it should be fixed as originally suggested by mpsuzuki, without changing the logic, but preventing the warning. Graham -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Werner LEMBERG Sent: 09 October 2008 13:28 To: [EMAIL PROTECTED] Cc: freetype-devel@nongnu.org Subject: [ft-devel] Re: meddlesome compiler warns against for( ...; ...;...) ; During the play with legacy CodeWarrior and MPW, I found these legacy C compilers warn the coding style like for ( i = 0 ; i N ; i++ ) ; ... They guess ; is a mistake (by the author) and the procedure ... is expected (by the author) to be looped. Of course it's a mistake! Please fix it as you prefer. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] freetype on the iPhone mentioned
FreeType is also the font engine in the Symbian and RIM operating systems. I know, because I put it there. And they are closed-source systems, although I believe Symbian is moving to open-source. There is no licensing difficulty as long as the use of FreeType is acknowledged. Graham Asher -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leon Woestenberg Sent: 25 September 2008 19:59 To: David Turner Cc: Behdad Esfahbod; freetype-devel@nongnu.org Subject: Re: [ft-devel] freetype on the iPhone mentioned Hello, On Sun, Sep 14, 2008 at 12:23 AM, David Turner [EMAIL PROTECTED] wrote: we don't know if they use FreeType to render glyphs. maybe they've taken a few lines of source code to parse certain tables, or whatnot :-) With Freetype being GPL (x)or modified BSD licensed*, doesn't this mean that either: - under GPL license, the complete Freetype dependent software should be GPL - under BSD license, non of the other software may be GPL? Does this mean that *if* Freetype is being used in iPhone, and the sources are kept closed, the BSD license must thus apply, and thus non of the dependent software may be GPL (due to the BSD/GPL license). on the other hand, I confirm you that FreeType is used as the font engine in Android. cheers - David I am not interested in nitting about the iPhone, I just want to understand how this applies to other semi-closed products who would like to use Freetype? Regards, -- Leon *http://www.freetype.org/license.html ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Rotated text
Frank, I've added some brief answers to your questions below. Best regards, Graham -Original Message- From: Frank W. Miller [mailto:[EMAIL PROTECTED] Sent: 07 July 2008 04:59 To: 'Graham Asher'; freetype-devel@nongnu.org Subject: RE: [ft-devel] Rotated text Thanks very much for the reply. I have a few questions as you might guess. Your mapping software looks really great btw. FM -Original Message- From: Graham Asher [mailto:[EMAIL PROTECTED] Sent: Sunday, July 06, 2008 5:19 AM To: 'Frank W. Miller'; freetype-devel@nongnu.org Subject: RE: [ft-devel] Rotated text Frank, I'm sorry that I don't have time to look at your example, but I have successfully drawn rotated text (and text along a path, for that matter) using FreeType, and I can give you some pieces of advice. 1. Either (i) use an FT_Matrix to set the font transform (call FT_Set_Transform), or (ii), create an unrotated outline glyph for each character and then rotate it using FT_Glyph_Transform. I assume from the fact that you say that your code 'spins' the text that you know how to set the transform parameters. FM: I have been using both FT_Matrix and FT_Set_Transform successfully as you have guessed. I've had a little trouble figuring out where 0 degrees is. In the sample code on the FreeType site, it seems to be the positive y axis. When I tweaked it, I was able to get that go be the positive x axis, which seems more logical to me. GA: It doesn't matter where 0 degrees is - 0 degrees can be regarded as 'unrotated'. 2. Use the advance vector after it has been transformed. This is outline_glyph-root.advance (assuming that outline_glyph is your FT_OutlineGlyph object), and is a 16.16 fixed-point number. You will need to keep track of the current glyph origin in 16.16 format, to avoid the text 'looking like arse', because... FM: The way the code works, there is a pen variable of type FT_Vector. The pen x and y components are set to the origin prior to entering a for loop. Each iteration of the for loop does this: 1) FT_Set_Transform 2) FT_Load_Char, 3) draw the bitmap, and 4) advance the pen using the face-glyph-advance. It seems like one of two things is happening, either my rendering of the bitmap does not fall on the baseline correctly or the pen advance is not following the baseline. My guess is its my bitmap rendering but I don't know for sure. GA: You need to store your pen variable in 16.16 coordinates. Add the x component of face-glyph-advance to pen.x and the y component to pen.y after drawing each glyph. 3. When you rasterize every glyph except the first one, it needs to be offset to the sub-pixel position of its origin. For example: if your first glyph has an unrotated baseline length of 8 pixels and you rotate the text by 20 degrees, the rotated advance will be (8 * cos 20,8 * sin 20) = (7.518, 2.736). Thus, if your first glyph origin was at (0,0), your second glyph origin needs to be at (7.518,2.736) to avoid a jiggling effect. Do this by applying an offset of the fractional parts of the coordinates to each glyph as you rasterize it, then drawing the glyph at the integer coordinates. Thus, in this example, you need to offset the glyph by (0.518,0.736) and draw at (7,2). FreeType works in 64ths of pixels when rasterizing, so you do this by calling FT_Glyph_Transform with a delta argument of (0.518 * 64,0.736 * 64) = (33,47) before converting the outline glyph to a bitmap. FM: Huh? This makes me wonder even more what I'm doing in my previous comment. Is my baseline length my width or pitch from the previous glyph? This is what's causing me trouble I think. Maybe I'm too new to this but there aren't that many things I can play with here, at least from what I see in the documentation. I do the rotation using the matrix. I use width and pitch and rows to figure out the bitmap size and I can take the advance.x 6 and advance.y 6 to get movements on the origin of each glyph. I'm not following where your application of the rotation angle to the baseline length is coming from. Can you be more specific about what fields in what structures you are talking about? GA: The baseline length ( that is, the advance, measured along the baseline) is the vector length of the advance. To use my previous example, the baseline length is 8 pixels - the value before rotation. The glyph bitmap pitch is irrelevant. You say and I can take the advance.x 6 and advance.y 6 to get movements on the origin of each glyph but that is a mistake. advance.x and advance.y are stored in 16.16 format. To convert to 64ths of a pixel (26.6 format) you need to shift right by 10, not by 6. You also said I'm not following where your application of the rotation angle to the baseline length is coming from. Can you be more specific about what fields in what structures you are talking about? Yes: FreeType applies the rotation to the advance in FT_Glyph_Transform. The code is FT_Vector_Transform( glyph-advance, matrix ); which
RE: [ft-devel] patch for Type1 Unicode cmap on Windows
U+00A0 is not a space but a non-break space, so something is wrong here surely? Graham Asher -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sergey Tolstov Sent: 08 May 2008 07:00 To: freetype-devel@nongnu.org Subject: [ft-devel] patch for Type1 Unicode cmap on Windows Hello, Type 1 driver uses Adobe Glyph List to build the Unicode cmap. Windows GDI creates a little different mapping. For example, if there is 'periodcentered' glyph name in the Type 1 font, Windows maps 0x2219 to that glyph and freetype does not. I have run AGL 2.0 and WGL4 through a script and found that there are the following glyph names in WGL4, which are mapped to additional Unicode values: Delta 0x0394 Omega 0x03A9 fi 0xF001 fl 0xF002 fraction0x2215 hyphen 0x00AD macron 0x02C9 mu 0x03BC periodcentered 0x2219 space 0x00A0 uni203E 0x203E Out of these, the fl and fi are not mapped by Windows, and uni203E can be omitted. This leaves 8 WGL specific mappings. Delta: 0x0394 Omega: 0x03A9 fraction: 0x2215 hyphen: 0x00AD macron: 0x02C9 mu: 0x03BC periodcentered: 0x2219 space: 0x00A0 I suggest you to consider a patch for the psmodule.c, which maps these glyph names on top of regular AGL mapping. The mapping is created if the glyph name is present in the font, and the Unicode value is not assigned by the AGL mapping. The patch is made on top of 2.3.5. During testing with a font, named Agate, 6 additional entries are being created in the unicode cmap (for 2215, AD, 2C9, 3BC, 2219, A0). With the patch, freetype maps those unicodes in the same way as GDI. Those unicodes are mapped to 0 without the patch. Thanks, Sergey Tolstov ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Adding edge effects
For a simple shadow effect, draw the glyph offset from its normal position by, say, 2 pixels in each dimension, then draw it in its normal position. You can improve on this by drawing the glyph in white at an intermediate position between the two positions, to separate the shadow from the actual glyph; and by drawing the shadow at lower intensity, etc. Graham Asher -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sarathks Sent: 25 April 2008 12:51 To: freetype-devel@nongnu.org Subject: [ft-devel] Adding edge effects Hi Does any body know how effects like shadowing and embossing applied on character images? What all changes should I make..? Any patches available..? -- View this message in context: http://www.nabble.com/Adding-edge-effects-tp16894922p16894922.html Sent from the Freetype - Dev mailing list archive at Nabble.com. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] limiting the heap memory used by a TrueType font
David,
I realise that in the case of memory-mapped data this is not needed (you
speak to one who has been single-stepping through the code, and modifying
it). I should have clarified my first message by explaining that I am
working with a platform where the data is stored in segmented form in Flash
memory that is subject to relocation, and thus, although the stream
interface works very fast, because it has access to the pointers to the data
segments, it cannot be dispensed with. I expect that this is a common
situation.
However, what I have done is essential for the platform I am working on, and
may well be essential for other low-RAM devices. In my current work we can
use large TrueType fonts (~2BM Japanese fonts, for example) successfully
with my changes; we cannot use them without my changes. Also, my CMAP code
is entirely non-invasive; it doesn't change the FreeType code or API at all
but is an optional add-on. (You call a function that gets the memory offset
of the charmap, stores it, then unloads the CMAP table; then you use a
replacement function instead of FT_Get_Char_Index.)
Note also that what I propose is optional; and can be tuned to affect CMAP,
LOCA, etc., tables above a certain size only; and if made a run-time option
rather than a compile-time option (I mentioned this in my first message),
can be made to work only for non-memory-mapped files.
I don't think making FT_Get_Char_Index use a stream interface would cripple
text layout performance. I have no benchmarking to back that assertion up
yet, I admit, but my experience when profiling is that TrueType rendering is
dominated by rasterization. The stream interface will often (as is the case
with my current work) have access to the data in the form of a series of
discontinuous memory blocks; that is, the file is memory-mapped but
segmented and thus requires a stream interface, but the overhead is
relatively low because the data is actually in memory.
Further, getting a glyph location from the LOCA table requires a only one
seek and two reads; there is no very good reason for copying the LOCA table
into RAM.
Here is a working and tested alternative version of tt_face_get_location; in
this code, the pointer face-glyph_locations has been replaced by an offset
face-glyph_locations_offset.
FT_LOCAL_DEF( FT_ULong )
tt_face_get_location( TT_Face face,
FT_UInt gindex,
FT_UInt *asize )
{
FT_ULong pos1, pos2;
FT_ULong p;
FT_ULong p_limit;
FT_Stream stream = face-root.stream;
FT_Error error = 0;
pos1 = pos2 = 0;
if ( gindex face-num_locations )
{
if ( face-header.Index_To_Loc_Format != 0 )
{
p = face-glyph_locations_offset + gindex * 4;
p_limit = face-glyph_locations_offset + face-num_locations * 4;
error = FT_Stream_Seek(stream,p);
pos1 = FT_Stream_ReadLong(stream,error);
pos2 = pos1;
if ( p + 4 = p_limit )
pos2 = FT_Stream_ReadLong(stream,error);
}
else
{
p = face-glyph_locations_offset + gindex * 2;
p_limit = face-glyph_locations_offset + face-num_locations * 2;
error = FT_Stream_Seek(stream,p);
pos1 = FT_Stream_ReadShort(stream,error) 0x;
pos2 = pos1;
if ( p + 2 = p_limit )
pos2 = FT_Stream_ReadShort(stream,error) 0x;
pos1 = 1;
pos2 = 1;
}
}
/* It isn't mentioned explicitly that the `loca' table must be */
/* ordered, but implicitly it refers to the length of an entry */
/* as the difference between the current and the next position. */
/* Anyway, there do exist (malformed) fonts which don't obey*/
/* this rule, so we are only able to provide an upper bound for */
/* the size.*/
if ( pos2 = pos1 )
*asize = (FT_UInt)( pos2 - pos1 );
else
*asize = (FT_UInt)( face-glyf_len - pos1 );
return pos1;
}
In conclusion I believe that what I have done is not only useful - in fact,
essential - to my current project but of potential use to FreeType users on
other devices with limited heap memory.
Best regards,
Graham
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of David Turner
Sent: 14 December 2007 14:17
To: Graham Asher
Cc: freetype-devel@nongnu.org
Subject: Re: [ft-devel] limiting the heap memory used by a TrueType font
Hi Graham,
first, keep in mind that the 'loca' table, as well as many other ones, are
simply never copied in the heap if the font file is already memory-mapped.
this happens if you use FT_New_Memory_Face, or even FT_New_Face if your
underlying stream implementation supports memory-mapped files (the Linux one
does). in these cases, all accesses
