Re: [ft-devel] Conditionalize Bzip2-compressed font support for inflexible dynamic linker platforms
During the business trip, I was trying to reproduce the trouble that Dave Viner got in http://lists.gnu.org/archive/html/freetype/2006-05/msg00035.html , and I found I made an overestimation about bad impact of the chained dependency. Please let me explain. [...] Thanks for the analysis! I'm now going to prepare a new release. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Math error? Spacing drastically different VS2005 to GNU/ARM (v2.4.4)
My question is: where should I look and/or what should I change, to make them act the same? The FT_INT64 stuff is only used in a single file, `src/base/ftcalc.c'. However, AFAIK, the GNU C compiler always defines a 64bit data type (`long long int'), so I'm really surprised that you experience this problem. Perhaps this is different for GNU C on ARM? Can you try make devel make (from a fresh tarball) for compiling FreeType so that you bypass the `configure' script? Do you then get correct results for your demo application? Can you please also post the file `builds/unix/config.log' (compressed)? In particular, it appears to me that the ARM system is doing some incorrect math from the metrics width value of 0x2C0 to get 0x800, but I'm having trouble identifying why this might be. Finally, can you decorate the various functions of ftcalc.c with some printf calls to find out where the difference comes from? Up to now, we've never received a similar problem report. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] Improve FT_MulFix
I've verified that replacing #undef FT_CONFIG_OPTION_FORCE_INT64 with #define in include/freetype/config/ftoption.h does prevent the #undef FT_LONG64. But that shouldn't be needed on LP64 archs. Perhaps the #if FT_SIZEOF_LONG == 8 case should also #define FT_CONFIG_OPTION_FORCE_INT64 ? For the dumb guy I am this sounds reasonable :-) What about `make devel; make' which checks ANSI compliance also? If everything's fine, please post a complete patch again so that I can apply it. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Math error? Spacing drastically different VS2005 to GNU/ARM (v2.4.4)
In particular, it appears to me that the ARM system is doing some incorrect math from the metrics width value of 0x2C0 to get 0x800, but I'm having trouble identifying why this might be. Finally, can you decorate the various functions of ftcalc.c with some printf calls to find out where the difference comes from? Up to now, we've never received a similar problem report. Another possibility is that the ARM specific multiplication routines are buggy... I've just updated `builds/unix/ftconfig.in' with the additional assembler routines from `include/freetype/config/ftconfig.h', but this shouldn't make a difference for you, I believe. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ftgrid improved
ftgrid has been improved. . Added key `f' to ftgrid to toggle forced autohinting. This might be interesting for some of you since you can toggle vertical and horizontal hinting independently. . Autofit debugging messages can now be controlled via FT_DEBUG_AUTOFIT in ftconfig.h (AF_DEBUG is gone). . The keys `1', `2', `3', `H', `V', and `B' of ftgrid have been disabled if FT_DEBUG_AUTOFIT is not set. . If you say `make devel', FT_DEBUG_AUTOFIT is defined by default. Please test. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Hinting glitch?
Attached is how the font NanumGothic.ttf (downloadable from here : http://hangeul.naver.com/download.nhn scroll down to the 7 green boxes and it's the third one along the top row) looks: @ Pixel Size 13 [cid:C2DDDF1F-E850-4D87-B865-45318241A5C1] Notice how the letter i appears to be too tall in relation to the other letters. @ Pixel Size 14 Now the i looks ok: [cid:FD1C366E-B3AA-4D86-ADF4-BCEEB6D2BC19] When hinted with the FT hinter, the letter i remains consistent. I can confirm this observation, however, I don't see any problem with the FreeType code, and debugging doesn't show a problem either: There is no border case which could cause a rounding to a different vertical value. It would be interesting to see what Windows does, testing with both ClearType switched on and off. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Any tool that visually present segments of autofit module?
A few months ago you've written: Are there any tool which visually present segments of autofit module? Something like stems shown in the glyph view of fontforge. No, but I'll probably add this to ftgrid since it would be helpful for my work on the ttfautohint stuff. But it isn't an urgent issue, and in case you have time to implement it I would be very grateful :-) It seems that ftgrid can dump autofit segment data to the terminal. But it's awkward to use with no label on the axis. Yep, another thing which should be added. Besides, that function was broken. I attached a patch to re-enable the function. Thanks. I've fixed that differently in ftgrid so that you get dumps only if the autofitter is active. The ftgrid binary need to be recompiled against a freetype lib with AF_DEBUG defined. I see no benefit of this forced recompilation other than a slightly less symbol pollution. Again, I've applied a different solution by replacing the local AF_DEBUG with a global FT_DEBUG_AUTOFIT macro in `ftoption.h' which is enabled by default if you say `make devel; make'. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Also I attached the comparison of 3 typefaces. Just a general question: Are you using B/W rendering in your images for demonstration purposes only? At such small sizes, the autohinter produces bad results if not using AA rendering. Even with TT instructions, CJK fonts normally contain bitmap strikes for these sizes to avoid rendering issues... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH by default?
Every user of FreeType that I know has once in their lifetime hit the bug that with many common CJK fonts, non-CJK characters take doublewidth where they should take a single one. The fix always has been to pass FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH to FreeType, as the fonts have the bit set wrongly. A monospace CJK font is never monospace. It has single-width glyphs, and double-width, hence setting global-advance is wrong in the font. But since this is such a common issue, I wonder if FreeType should simply ignore global advance by default. Cairo and fontconfig always pass that flag to FreeType. I've seen this bug hit Qt before. And most recently I watched it hit Skia. I've already pondered about this problem, but I've found no solution which guarantees backwards compatibility. Your idea of completely ignoring this flag didn't come to my mind :-) Since your suggestion sounds sensible, could you provide a patch? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] CJK Autohinter should not clump stems together when there are too many of them
One of my anxiety was that the priority to the black/white evenness can reduce the contrast of the complex glyph. Please find attached picture comparing the results by HeiseiMaruGo-W4 at 16pt @ 72dpi. In my personal impression, the legibility of the strokes in enclosed area (like 日 or 目) is not important, but the legibility of the longest stroke should be respected. Please let me know how your opinion. Thanks for reviewing. Do you have an idea how to increase the legibility of the longest strokes? Contrary to the proposed patch I think that this what you suggest is quite hard a job to achieve since you not only have to do feature analysis, e.g., mark horizontal stems which are surrounded by vertical stems like this |-| as `unimportant', but also distort the glyph accordingly so that `important' stems are aligned to the grid... Please commit to the git repository if you think that your reviewed patch is OK now. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH by default?
Since your suggestion sounds sensible, could you provide a patch? Attached. Applied, thanks. You also need to update the ft2demos that use it to remove the option (ftdiff, etc). Done too. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] more Unicode character blocks for Indic autofitting
I propose following update as the minimum back-compatible patch for next release of FreeType2. Please decide yourself which of the two patches should go into the repository. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
There are indeed some problems with the patch. They happened when the bluezones were scaled at af_cjk_metrics_scale_dim() [...] I update the patch to the current git and address the problems. Please review the logic behind the idea. Thanks! I leave this to Toshiya-san for testing. There could be other improvements when scaling the bluezone. Like under small size, round the bluezones to the ceiling unconditionally. That could make glyph bigger and clearer. But could make it 1 pixel extra bigger than the intended size. Well, what is the `intended size'? As we all know, it's impossible to exactly find out the bbox of a glyph string without actually rendering it, and it rarely happens that you get for, say, a 10pt font at 72dpi a bbox height of 10 pixels. Additionally, bytecode instructions in TrueType fonts modify the size also, sometimes rather drastically -- in other words, I don't mind if a patch increases the size by one pixel if legibility improves, provided this size fits (more or less) with the non-CJK glyphs in the same font. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Any tool that visually present segments of autofit module?
Are there any tool which visually present segments of autofit module? Something like stems shown in the glyph view of fontforge. No, but I'll probably add this to ftgrid since it would be helpful for my work on the ttfautohint stuff. But it isn't an urgent issue, and in case you have time to implement it I would be very grateful :-) OK, I made a simple patch to draw the segment data. I have to copy afhints.h and aftypes.h to the src/ directory because I really need some structs from autofit/. Thanks a lot! Do you have time to refine the patch? I very much dislike the use of afhints.h and aftypes.h within the user space. Could you instead add debug hooks to afhints.c which can be used for communication? The simplest form could be something like these two functions: FT_Error af_glyph_hints_get_num_segments(AF_GlyphHints hints, int dimension, FT_Int* num_segments); FT_Error af_glyph_hints_get_segment_offset(AF_GlyphHints hints, int dimension, FT_Int idx, FT_Pos* offset); Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
Considering that the number of blacklist is increased to 13, I changed the algorithm to compare the checksums slightly. It seems that the fonts are not so popular, so this is not urgent issue. Please give me comment. Your patch looks fine. I haven't tested actually whether it works, but i trust you :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
BTW, during the production of sample PDF, I found that OpenOffice.org generates wrong checksum for embedded TTF, so the tricky font detection by the checksum cannot solve the problem :-( Uh, oh. Please write a bug report to the OpenOffice/LibreOffice people. It seems to me that we can't do more on the FreeType side to make the fonts work. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
For some reason I assumed that FreeType would be calculating the checksum. I'm sure there's lots of code that doesn't bother to set the checksums at all. The problem are subsetted fonts, I believe. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint: fun with assembler code
I've had some hope to show working bytecode stuff at the beginning of May, but things are a bit more complicated, unfortunately: While the library has been extended to support generated bytecode already, I have first to define some auxiliary bytecode functions to support hinting similar to FreeType's autohinter. On the other hand, I have now an outline how things will work: I will run the autohinter for a set of sizes which are then hardcoded as bytecode. Contrary to the autohinter, TrueType instructions can only handle integer values for PPEM sizes; this reduces a lot the number of configurations to test for. Some weeks ago I've adapted the autohinter logging stuff to standard FreeType tracing (at level 5); now can you actually see the `high-level hints' the autohinter is going to apply with the usual tracing methods as outlined in FreeType's `DEBUG' documentation file. As an example, here are the messages for vertical hinting of glyph `R' from pala.ttf at the 10ppem: BLUE: edge 0 (opos=0.00) snapped to (0.00), was (0.00) LINK: edge 1 (opos=0.30) linked to (0.30), dist was 0.30, now 0.30 BLUE: edge 4 (opos=7.34) snapped to (8.00), was (7.34) LINK: edge 3 (opos=6.97) linked to (7.62), dist was -0.38, now -0.38 SERIF_LINK1: edge 2 (opos=3.95) snapped to (4.31) from 1 (opos=0.30) I'll skip a detailed explanation here; you might read the comments in file `afhints.h' for more. The most important fact which can be seen from the above output is that `LINK' commands don't snap to pixel borders. This is intentional. Except for blue zones where either the top or the bottom line of a stem gets aligned with a pixel border (the width of small stems gets increased if necessary), the autohinter aligns the *center* of stems, applying some rounding voodoo to the stem width. To imitate this behaviour, I'm diving right now into the world of writing bytecode assembler code. Here an example. The following code is taken from `af_latin_compute_stem_width', transformed into some pseudo code which can be easier converted to bytecode: Function: compute_stem_width in: width is_serif is_round out: new_width CVT: std_width dist = ABS(width) if is_serif dist 3*64: return width else if is_round: if dist 80 dist = 64 else: dist = MIN(56, dist) delta = ABS(dist - std_width) if delta 40: dist = MIN(48, std_width) goto End if dist 3*64: delta = dist dist = FLOOR(dist) delta = delta - dist if delta 10: dist = dist + delta else if delta 32: dist = dist + 10 else if delta 54: dist = dist + 54 else dist = dist + delta else dist = ROUND(dist) End: if width 0: dist = -dist return dist This corresponds to the following (still untested) bytecode: // In the comments below, the top of the stack (`s:') // is the rightmost element. // Function 0: compute_stem_width // // in: width // is_serif // is_round // out: new_width // CVT: std_width 0xB0, // PUSHB_1 0x00, // 0 0x2C, // FDEF 0x20, // DUP 0x64, // ABS -- s: is_round is_serif width dist 0x20, // DUP 0xB0, // PUSHB_1 0xC0, // 3*64 0x50, // LT -- (dist 3*64) 0xB0, // PUSHB_1 0x04, // 4 0x26, // MINDEX -- s: is_round width dist (dist3*64) is_serif 0x5A, // AND -- (is_serif dist 3*64) 0x58, // IF -- s: is_round width dist 0x21, // POP 0x23, // SWAP 0x21, // POP -- s: width 0x1B, // ELSE 0x8A, // ROLL -- s: width dist is_round 0x58, // IF -- s: width dist 0x20, // DUP 0xB0, // PUSHB_1 0x50, // 80 0x50, // LT -- (dist 80) 0x58, // IF -- s: width dist 0x21, // POP 0xB0, // PUSHB_1 0x40, // 64 -- dist = 64 0x59, // EIF 0x1B, // ELSE 0xB0, // PUSHB_1 0x38, // 56 0x8C, // MIN -- dist = min(56, dist) 0x59, // EIF 0x20, // DUP -- s: width dist dist 0xB0, // PUSHB_1 %c, // index of std_width 0x45, // RCVT 0x61, // SUB 0x64, // ABS -- s: width dist delta 0xB0, // PUSHB_1 0x28, // 40 0x50, // LT -- (delta 40) 0x58, // IF -- s: width dist 0x21, // POP 0xB1, // PUSHB_2 0x30, // 48 %c, // index of std_width 0x45, // RCVT 0x8C, // MIN -- dist = min(48, std_width) 0x1B, // ELSE 0x20, // DUP -- s: width dist dist 0xB0, // PUSHB_1 0xC0, // 3*64 0x50, // LT -- (dist 3*64) 0x58, // IF 0x20, // DUP -- s: width delta dist 0x66, // FLOOR -- dist = FLOOR(dist) 0x20, // DUP -- s: width delta dist dist 0x8A, // ROLL 0x8A, // ROLL -- s: width dist delta dist 0x61, // SUB -- delta = delta - dist 0x20, // DUP -- s: width dist delta delta 0xB0, // PUSHB_1 0x0A, // 10 0x50, // LT -- (delta 10) 0x58, //
Re: [ft-devel] benchmark of sfnt checksum recalculation
Here is 2nd testcases checking ca. 1900 fonts [...] Thanks. Since this is a once-per-font operation, I don't think we should think too much about timing issues. Please proceed. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] benchmark of sfnt checksum recalculation
Just I've committed to make tricky font detector to ignore the existing checksum written in the TrueType header, [...] Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] configure option to disable mmap()
At present, configure script always uses mmap() if it is found, so I added an option --disable-mmap to ignore it. Although this is only for developers who want to make irregular configuration, is it meaningful to merger in official source code? If you think this is useful, please add it! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Any tool that visually present segments of autofit module?
Okey, I add the accessor functions to afhint.c. I also made the segment drawing independent of the force autofit mode. I found that the segment lines are useful reference with or without autofit turned on. Applied with modifications, thanks. One observation I had is that in order to have the outlines merge with the segments into one, I have to 1. turn on force autofit (f) 2. turn of Horizontal and Vertical Hinting (H and V) 3. turn on hinting (h) Otherwise, there are always some offset between the outlines and the segments. Reason is that segment offsets are based on font units and thus not dependent on the device resolution; they are computed before any hinting gets applied. The first resolution dependent step in the autohinter is the bundling of segments into edges. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] AutoFit: Treat extrema of contours as edges for CJK glyph?
For CJK glyph, There are alway many diagonal stems that needed to be fit with blue zones. However, since we cannot produce a horizontal or vertical segment out of a diagonal stem, the stem cannot be blue zoned, e.g. the top and the bottom of 户. To solute the problem, I suggest to treat the extremas of every contours in a glyph as edge lines. Then we can blue zone the edges so that diagonal stems can also be aligned at top and bottom. Sounds interesting and shouldn't be too hard to implement. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Use tt_face_get_name() in sfnt_get_ps_name()?
If these difference is not so important, I propose to change sfnt_get_ps_name() to thin wrapper of tt_face_get_name(). Looks good. If you don't notice adverse effects please commit. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem with Postscript Hint
I find the random generator, but it can’t explain what I’m experiencing. Have you read this comment in the description of FT_Library For multi-threading applications each thread should have its own FT_Library object. and are you following the advice? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem with Postscript Hint
Question for the FT developers : why was this seed calculation implemented this way ? And not e.g. a fixed start value associated with each FT_Face created ? That would make FT output reproducable (and testable for detecting regressions). I have no idea. :-) Patches are welcome. Up to now I've never seen a real PS font which actually uses random numbers for defining its shape, so this is really a minor issue, necessary only to test the CFF `random' operator (and similar stuff in other PS flavours). BTW, if you have such a font I would be glad if you can send it to me offline for my font test collection. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Culprit for missing segment at the ends of stems.
It turned out that the culprit was, that the surrounding anchor points have no 'out direction' when searching for segments. [...] Cross out that part will solve the problem for 一 , of cause might also screw up some other parts. It's there to keep the tangent small. Any suggestion on how to fix it properly? I can imagine to take the segment length into account: The longer the segment, the steeper the accepted tangent. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: fun with assembler code
Thanks for you suggestions! Working with bytecode instructions must be actively trained, like any other programming language, then the obstacles diminish. Maybe you can make use of the xgridfit tool to semi auto-gen the TT instructions. Maybe. However, the idea was to write a library in C, not dependent on other external programs. In the last few days I make good progress (for example, code for creating a `prep' table has been added together with some more `fpgm' functions), and it will take just a few days, I believe, to have first (bad) hinting results. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Tweak CJK Blue zone parameters
How long do you need to find stable values for the tunable parameters? This is never finished :-) Even for the latin autohinter, improvements or different approaches are always possible (cf. `latin2'). If it is difficult to estimate, I will propose new API to manipulate the parameters by FT2 clients. Please no. It may be useful to have an easy way to manipulate the hinting process at compile time with a granularity down to a particular glyph in a particular font at a particular size (cf. the Infinality ClearType patches which will be added to FreeType quite soon), but exposing the autohinter internals to the public prevents any major change to the code, if ever necessary. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] Compensate blue zone rounding after scale
In af_cjk_metrics_scale_dim(), when we scale the blue zone to the font size, the blue zone is also rounded to pixel grid. The offset introduced in the rounding at both the bottom and top could have undesirable effect on the glyph height at certain font size. [...] Again, it would be great if you can provide images which demonstrate the usefulness of your change. It seems that such a fix must be applied to the latin hinter also for consistency... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] builds/unix/install-sh is removed from GIT repository
builds/unix/install-sh is a file installed by automake, so it is modified when autogen.sh is executed. I think it is something like config.guess and ltmain.sh, so I registered install-sh to builds/unix/.gitignore and builds/unix/install-sh is removed from GIT repository. Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Improving documentation re vertical metrics
I'm adding vertical text support to HarfBuzz and it occurred to me that FreeType's vertBearingY and vertAdvance metrics have a Y coordinate growing downwards, while all other Y coordinates in FreeType grow upwards. Thought that may be worth documenting. Could you provide a patch, please? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Improving documentation re vertical metrics
How about this: Applied, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint: progress and problems
The last days there was a lot of progress in ttfautohint. I thought that the whole framework was finished, and I only had to fill up missing bytecode. However, while doing so, I found out that I've made a fundamental design error. The idea was (and still is) to compute and collect `hinting sets' for a large range of sizes, say, 8=ppem=1000. For each size a set of rules gets defined and compared to the previous ones. Only different sets get stored. Example: glyph 1327 in `pala.ttf' (the `CE' sign) has 9 sets for the following ppem values: 8 = set110 10 = set223 23 = set325 25 = set435 35 = set544 44 = set648 48 = set7 168 168 = set8 503 503 = set9 1000 In most cases, the number of sets is much less (usually three or four). The problem is that the way I've collected this data doesn't work. My assumption was that it is sufficient to simply examine the edges after the hinting has been done, then emitting bytecode for computing the actual edge positions. However, the autohinter does some actions which escape this scheme, making it necessary to record the hinting steps while they are executed so that they can be replayed later on. In other words, I have to redo a large part of the framework to fix this. Fortunately, it's not too difficult, but I think it will take a week before I can continue with bytecode stuff. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_IS_CID_KEYED() should ignore t1cid fonts?
Toshiya-san, sorry for the late reply. If you can remember why current FT_IS_CID_KEYED() ignores t1cid, please let me know. It simply looks like an oversight. I can't see any reason why t1cid fonts should be excluded. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] glyph name bug in verdana.ttf 5.03
[I'm CCing the FreeType and lilypond devel lists since this is a problem which has not been reported to FreeType, and which has caused problems with PS files created by lilypond.] Peter, the font `verdana.ttf' version 5.03 (shipped with Windows 7, I believe) contains the following two invalid glyph names: glyph 571 glyph 572 Note the space in the glyph names. Can you tell me in which font version this bug has been introduced? And is a newer verdana.ttf available already? If yes, do people get a new version with the standard Windows update mechanism? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint: twilight points
The last two days I've rewritten a large part of the bytecode in ttfautohint to use twilight points for representing segments. FreeType's autohinter treats segments as if they were a single point, located in the middle of the maximum and minimum coordinate value. The previous code in ttfautohint simplified this by using the first point of a segment (pars pro toto), and its location was saved in a storage area location. However, the deviation compared to the autohinter results was rather large. I've now fixed this by properly computing the middle positions for each segment, and I use two sets of twilight points to store these representations: The first set holds the original coordinates, the second one the hinted values. The reason for this is that all twilight points are originally located at (0,0), thus instructions like `MD[orig]' to access the original coordinates would always refer to (0,0) which is not really helpful. Unfortunately, I'm still behind my schedule, but there actually is a lot of progress! http://repo.or.cz/w/ttfautohint.git Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: Milestone reached!
[Vern, I take the liberty to answer on the list also.] That's very interesting and gives some pretty good results. If no-one else has done so i am happy to run some specimen tests produce screenshots. This would be great! Please wait a few days until I've fixed the problem with composite glyphs (I'm nearly done, and the solution was much easier than expected); I'll then send another mail to the list. Are there plans with ttfautohint to give the user any abilities to vary/manipulate hinting parameters? Yes. However, I need input from experienced designers like you who tell me what shall be configurable. The first parameter to be added is the size range covered by hinting. For the moment, it is fixed to 8=ppem=1000. Another one is whether the original font's outline shall be used, or whether the font's original hinting shall be applied (at the font units level, which means 2048 ppem for most TrueType fonts). Some fonts like ArialMT *always* apply hints to some composite glyphs to shift one or more subglyphs. Note that the latter option will probably take some time to implement. Finally, there is the problem of glyphs which can't be addressed with a cmap directly, like small caps which are activated by an OpenType feature. Similar to FreeType's autohinter, such glyphs don't get any special consideration and are treated by the default hinting module (in FreeType this is the `cjk' module currently, and in ttfautohint it can be either `dummy' or `latin', to be controlled by another yet-to-be-written configuration option :-). This is quite a generic problem and needs separate attention; for the moment it is beyond my work on ttfautohint. So please comment and make suggestions! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: Milestone reached!
I think i remember you saying that ttfautohint will not have a GUI. Is that still the case? Yes. ttfautohint is a library (with a single API function :-), and the `hint' program is just a small demo using it. Writing a GUI front-end might be a nice job later on, but it has no priority for me right now. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: Milestone reached!
One major problem still remains which I have to resolve in the next days: Composite glyphs are rendered incorrectly. I've fixed that now. However, letting the autohinter handle subglyphs separately will always produce inferior results if compared to handling all subglyphs together at the same time. In particular, diacritics are sometimes positioned too near to the base letter. So please test the library! As usual, comments, suggestions, critique, etc., is highly welcomed. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint: How to install
but i am embarrassed to admit that i have built the library but have not found how to use the 'autohint' function :) a quick howto, please! One important thing I've forgotten to mention: You need the current git version of FreeType to test the ttfautohint library; the `configure' test for 2.4.4 in ttfautohint is a fake currently since 2.4.5 hasn't been released yet. I know, I know, I should have done this already weeks ago :-| In case you are running a Unix box (this includes recent Macs), please use the attached script which downloads and builds ttfautohint and FreeType in a subdirectory called `ttfautohint-build'. For convenience, the created `ttfautohint' binary is static and not dependent on other libraries. After successful compilation, you can find it in `ttfautohint-build/out/bin', and you can copy it to any other directory. If you run the script another time, it will update the git repositories instead of downloading, then do a complete build again. Calling `ttfautohint' is simple: ttfautohint in-file out-file for example ttfautohint Bevan.ttf Bevan-TA.ttf As mentioned earlier, there aren't options right now. Note that the program runs quite slow; adding a progress indicator is on my TODO list also. For building the binary you need the following packages installed on your system: git autoconf automake libtool gcc (or any other compiler) ttfautohint should build on Windows also since it is a simple command line program and doesn't use exotic stuff, however, I haven't found time yet to learn how to cross-compile (since I don't use Windows at all :-). Werner #!/bin/sh test -a ttfautohint-build || mkdir ttfautohint-build cd ttfautohint-build test -a out || mkdir out if test -a freetype2; then cd freetype2 git pull cd .. else git clone git://git.sv.nongnu.org/freetype/freetype2.git fi cd freetype2 sh autogen.sh ./configure --disable-shared \ --prefix=`pwd`/../out \ --without-zlib \ --without-bzip2 make make install cd .. if test -a ttfautohint; then cd ttfautohint git pull cd .. else git clone git://repo.or.cz/ttfautohint.git fi cd ttfautohint sh autogen.sh ./configure --with-freetype-config=`pwd`/../out/bin/freetype-config \ --prefix=`pwd`/../out make make install # eof ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
Vern, I have now added some simple upper lowercase waterfall tests to 'ttfautohint tests' at http://code.newtypography.co.uk thanks a lot for the tests and the test images! Please post a URL where I can download the Ubuntu font you've used. Of note is that at larger sizes (20px - 30px) the rendering breaks up on curves. Is it possible that the autohinter is not yet set to instruct those larger sizes? What do you mean with `breaks up'? Please give more details what exactly you think is bad. The hinting range is set to 8ppem-1000ppem, BTW, so these sizes are covered. Overall it's looking good to me. There are specific issues at certain sizes, e.g uppercase bowls are flattening too abruptly at the cap-height, see 'O' at 15, 19, 21px, but i'm assuming these things can be tweaked away. Yes, this is what I've noted too. I'll look into it. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: Milestone reached!
Finally, there is the problem of glyphs which can't be addressed with a cmap directly, like small caps which are activated by an OpenType feature. Similar to FreeType's autohinter, such glyphs don't get any special consideration and are treated by the default hinting module (in FreeType this is the `cjk' module currently, and in ttfautohint it can be either `dummy' or `latin', to be controlled by another yet-to-be-written configuration option :-). With HarfBuzz it's quite easy to list every glyph that can be accessed through, say, the 'latn' GSUB table. I probably can provide some API for such introspection. That may solve your ttfautohint problem, but not FreeType's. Yes, this would be very helpful. For FreeType, there could be an interface to the autorhinter also, extending the table which defines the latin ranges. If I understand you correctly, there currently isn't a possibility to get such info from HarfBuzz easily (if at all)? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
The 'stretched' x-height could be a matter of taste, but personally i would like to see the autohinter err on the side of less stretching if possible. Hmm. I could add the ability to switch off x-size snapping, and I could also change the rounding rules to something similar the SROUND instruction offers. But IMHO the first option leaves a lot of fuzzy x-heights for various ppem values, and the second option just shifts the issue to different sizes. But maybe it makes it shift away from the `important' sizes... I'll add it to my TODO list. A gui to visibly tweak the pixel snap zones ;) Well, *that* I won't provide, I think :-) However, I'll think about how to make this easily editable, for example, by providing a simple bytecode function which accepts a list of sizes where x-size snapping should be disabled. This list could be given as a command line option. Also added to my TODO list :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
Mhmm. Up to now I've *never* seen a font rendered with FreeType which shows such a large deviation from the Windows font engine. I believe that FreeType's output is quite trustworthy. heh. Really? Depends what you mean by 'large deviation' i guess. I only ever seem to see differences between Windows font rendering and the other OS's :) Interesting. Could you give some examples? Are those problems related to FreeType? Maybe there are problems with my bytecode. Well - your bytecode seems to work fine for hinting under Freetype, but not under Windows GDI. Actually, I've found a problem: You should probably look at the newest screenshots at http://code.newtypography.co.uk I tested Ubuntu Font Droid Serif with the Windows' 'system font viewer' on XP and Win7, both with GDI-Cleartype. Some very glitchy stuff happens with the ttfauto hinted fonts at larger sizes - 36pts on Ubuntu Font, 48pts on Droid Serif. I have tested and replicated those glitches on different PC's so they are for real! :) Using ftview, I see problems with FreeType also: The baseline is ragged. And indeed, I've done an addition instead of a subtraction in the bytecode, making the computation of blue overshoot values incorrect. This is fixed now in the git repository; please update and regenerate your test files! Maybe this change is sufficient to improve the rendering with Windows GDI also. Must do some full waterfall tests to see what else is happening at other sizes. More testers and more eyes would be good too. Indeed! This is another reason why your messages should be sent to te ft-devel list. The rendering glitches seem to be specific to the GDI-Cleartype rendering, and absent (as far as i can see) from the new (FireFox4 IE9) DirectWrite-Cleartype rendering. Well, please report whether the current git gives better results. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fix for CVE-2010-3311
I am trying to audit our local patches to freetype2 in openSUSE to reduce the number of patches we apply. I noticed that fix for CVE-2010-3311 [0] is not applied to upstream freetype source. Attached is the fix for the issue with the demo CFF file. It would be nice to get this fixed so we can drop this patch. [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3311 Hmm, in https://bugzilla.redhat.com/show_bug.cgi?id=623625 I read this: Affected versions: freetype-2.3 and before that. Latest upstream version (2.4) is not affected. Actually, I remember this CVE... And indeed, comment #39 says: The following upstream commit fixes this problem in freetype 2.4.x: commit 75787c19eab20874c5d588842c52e59cfbd9302a Author: Werner Lemberg w...@gnu.org Date: Sat Jun 26 09:24:08 2010 +0200 Add some memory checks (mainly for debugging). * src/base/ftstream.c (FT_Stream_EnterFrame): Exit with error if the frame size is larger than the stream size. * src/base/ftsystem.c (ft_ansi_stream_io): Exit with error if seeking a position larger than the stream size. :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
Just posted screenshots of ttfautohint output under DirectWrite (Cleartype Grayscaling). Thanks again for your invaluable help in testing ttfautohint! Interesting. imo, generally the ttfautohint output is superior to the original fonts' output, though there are some glitches, e.g. dot accents are malformed. In general, composite glyphs will be inferior with ttfautohint; this is unavoidable. It will take some time until I've implemented an option to pre-hint all glyphs (and thus resolving the composites) to improve that at the cost of larger output files. Do you think it's possible that the autohinter can be tweaked to lessen the effects of the aggressive vertical filtering of GDI? or is it already at the limits of what's possible for GDI? The feedback i'm getting from my screenshots is that the ttfautohint output is overall superior under DirectWrite to the original hinted fonts. Just seems to be a little extra 'something' needed to get the GDI sorted too :) Please try the current git snapshot and play with the options --hinting-range-min and --hinting-range-max. Currently, the default value for hinting-range-max is 1000; this means that the autohinter tests all ppem values up to 1000 to find hinting sets. However, the larger the ppem, the larger the blue zones. And by design, the autohinter ignores blue zones which are larger than 3/4 pixels. If you limit hinting-range-max to a value where the blue zones are still handled, the generated bytecode uses this hinting set for all larger sizes also. Finding a good value for hinting-range-max has to be done with trial and error, but a waterfall already indicates bad sizes, so hinting-range-max must be less than that). The adverse effects of having a very small value for hinting-range-max must be analyzed also; it essentially means that some horizontal segments which at larger ppem values no longer align are still treated as edges. Maybe it helps if I introduce options to manipulate the `gasp' table, making it possible to set an upper limit for applying hints. Finally, I don't know yet whether it makes sense to directly manipulate the 3/4 pixels limit (perhaps by deactivating this threshold completely). This needs further testing. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType 2.4.5 has been released
FreeType 2.4.5 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/project/freetype/files/ The latter site also holds older versions of the FreeType library. See below for the relevant snippet from the CHANGES file; users of version 2.4.4 should upgrade. 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.4 and 2.4.5 I. IMPORTANT BUG FIXES - A rendering regression for second-order Bézier curves has been fixed, introduced in 2.4.3. II. IMPORTANT CHANGES - If autohinting is not explicitly disabled, FreeType now uses the autohinter if a TrueType based font doesn't contain native hints. - The load flag FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH has been made redundant and is simply ignored; this means that FreeType now ignores the global advance width value in TrueType fonts. III. MISCELLANEOUS - `FT_Sfnt_Table_Info' can now return the number of SFNT tables of a font. - Support for PCF files compressed with bzip2 has been contributed by Joel Klinghed. To make this work, the OS must provide a bzip2 library. - Bradley Grainger contributed project and solution files in Visual Studio 2010 format. - Again some fixes to better handle broken fonts. - Some improvements to the B/W rasterizer. - Fixes to the cache module to improve robustness. - Just Fill Bugs contributed (experimental) code to compute blue zones for CJK Ideographs, improving the alignment of horizontal stems at the top or bottom edges. - The `ftgrid' demo program can now display autohinter segments, to be toggled on and off with key `s'. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
I am curious - as i understand it(?) ttfautohint uses freetype to find snap zones etc from which it bases it's TT instructions output. I've copied a large part of the autofit module into ttfautohint; additionally, I'm calling some FreeType routines for generic reading and parsing of the input font. So what mileage could there be in using a patched freetype tree with ttfautohint? ttfautohint doesn't use a modified FreeType library. However, the copied autofit stuff has been slightly modified since I have to access various data structures which aren't publicly exposed normally. I'm thinking of some of Infinality patches that have attempted to tweak Freetype's hinting routines. Some i think were attempting to give more aggressive, cleartype-like rendering. The stuff from Erik regarding the autohinter is exactly this. However, I have yet to test whether I can `translate' it easily into bytecode instructions. Werner PS: BTW, I've delayed integration of Erik's patches until this release is out. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF bitmap foundary patch
in openSUSE we apply a patch called freetype2-bitmap-foundry.patch which seems to add foundry support to PCF font files, likely to fix the problem reported over at http://lists.freedesktop.org/archives/fontconfig/2006-February/002072.html . The patch is attached for your inspection, can anyone check if its useful still? It seems to be useful. However, I would like to have a better description what this fix is intended to do, with an example or a good bug report. I've CCed coolo, apparently the author of the patch; perhaps he or she can shed some light on this issue. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint 0.1 has been released
ttfautohint 0.1 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/project/freetype/files/ttfautohint Enjoy! Werner -- This project provides a library which takes a TrueType font as the input, remove its bytecode instructions (if any), and return a new font where all glyphs are bytecode hinted using the information given by FreeType's autohinting module. The idea is to provide the excellent quality of the autohinter on platforms which don't use FreeType. The library has a single API function, `TTF_autohint'; see `src/ttfautohint.h' for a detailed description. Note that the library itself won't get installed currently. A simple command-line interface to the library is the demo program `ttfautohint'; after compilation and installation, say ttfautohint --help for usage information, or say man ttfautohint to read its manual page. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint 0.1 has been released
ttfautohint 0.1 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/project/freetype/files/ttfautohint Oops! This should be http://sourceforge.net/projects/freetype/files/ttfautohint Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
The 'final image' is simply the ttfautohint instructions with the addition of links (double links work best in this instance). I did no extra hinting from fontlab - [...] [...] if i look at the same font in FontForge's Gridfitmode, then i don't see the egging issue at all. Exactly! Such a big deviation between the rendering results indicates a severe problem IMHO. The only possible explanation I have so far is that the MS Windows rasterizer never sees the IUP[y]. It's the last instruction in the `fpgm' table, only followed by a final ENDF. Maybe I've somehow incorrectly implemented the generation of this SFNT table, but ttx doesn't show any error, and a round-conversion gives the same size and checksum of the `fpgm' table... Just to be sure that an incorrect `fpgm' size isn't the problem I ask you to try the attached font. With FontForge, I've stripped off all glyphs but uppercase `O', then I've disassembled it with ttx, omitting the `FFTM', `GDEF', `GPOS', and `GSUB' tables, then added a dummy function at the end of the `fpgm' table to make it bigger, and finally assembled it again with ttx. Werner Ubuntu-R-TA-only-O.ttf Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] .gitignore in release tarballs
our building system warned me that there are .gitignore files distributed in release tarballs of freetype. Could you remove them in upcoming releases? Why should .gitignore files be removed from release tarballs? They're part of the source code. Mhmm, not really IMHO. For me, `.gitignore' is rather an administrative metafile (like the `.git' subdirectory). Consequently, such files make only sense in the git repository but not in the tarball. OK, I just thought that you don't want git specific files there since you've removed git specific directories. I'll workaround it in freetype's spec file. If you are in a hurry, please provide a patch so that `make dist' ignores those files :-) Otherwise, I'll fix this, but without any guarantee of a time frame. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] .gitignore in release tarballs
Since freetype no longer uses CVS attached patch could do the job. Applied, thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] stroker fixes
Please find attached a major revision of ftstroke.c/h. Thanks a lot! I've committed it to the git repository, doing some slight formatting. Ideally, it would have been better to isolate the various unrelated fixes into separate commits, but I know that this can be a very time-consuming burden. So I ask everyone to test it! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] stroker fixes - documentation
I think only the documentation for FT_Stroker_LineJoin will need updating to match the new ftstroker.h. Perhaps this happens automatically. It does, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
What i have noticed with ttfautohint is that often e.g. a regular weight of a font will grow in size at a bigger % than the bold weight. So i'm thinking the Regular is 'over-hinted', maybe. Well, ttfautohint has no possibility to decide whether a font is bold or not... The Infinality patches, however, try to cater with such a situation, giving different thresholds for bold shapes. I haven't checked yet whether this harmonizes (in your sense) the appearance of regular and bold weights. If this works as expected I could add an option to ttfautohint to make it treat the font to be processed as bold. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Improved handling of ascender and descender
Folks,
I'm going to apply the change below (in sfnt/sfobjs.c). Only if a
font has zero values for `hhea' table's ascender and descender,
FreeType tries harder to find reasonable values.
Any objections?
Werner
==
old code:
root-ascender = face-horizontal.Ascender;
root-descender = face-horizontal.Descender;
root-height= (FT_Short)( root-ascender - root-descender +
face-horizontal.Line_Gap );
==
new code:
root-ascender = face-horizontal.Ascender;
root-descender = face-horizontal.Descender;
root-height = (FT_Short)( root-ascender - root-descender +
face-horizontal.Line_Gap );
if ( !( root-ascender || root-descender ) )
{
if ( face-os2.version != 0xU )
{
if ( face-os2.sTypoAscender || face-os2.sTypoDescender )
{
root-ascender = face-os2.sTypoAscender;
root-descender = face-os2.sTypoDescender;
root-height = (FT_Short)( root-ascender - root-descender +
face-os2.sTypoLineGap );
}
else
{
root-ascender = (FT_Short)face-os2.usWinAscent;
root-descender = -(FT_Short)face-os2.usWinDescent;
root-height = (FT_UShort)( root-ascender - root-descender );
}
}
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
Attached is a patch for tafpgm.c; please apply temporarily to make the `fpgm' table four bytes longer. Thanks for that. Have you been able to test that? Are fonts generated with the slightly larger `fpgm' table rendered correctly, or do you still get an egg-shaped `O' glyph? Otherwise, I'm going to contact Greg Hitchcock from Microsoft, asking for help. Perhaps he can explain what's going on. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
My patch file looks like this (taken from your post) -
diff --git a/src/tafpgm.c b/src/tafpgm.c
index 1268e29..3874844 100644
--- a/src/tafpgm.c
+++ b/src/tafpgm.c
@@ -4298,6 +4298,11 @@ unsigned char FPGM(bci_hint_glyph) [] = {
ENDF,
+ PUSHB_1,
+100,
+ FDEF,
+ ENDF,
+
};
Yep, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] details on iPhone exploit caused by FreeType?
Folks, has anyone more information on the recent exploit for the iPhone, reportedly caused by a problem within FreeType's `t1_decoder_parse_charstrings'? Extracting the buggy font from http://www.jailbreakme.com/saffron/_/iPod_4.3.3_8J2.pdf and testing the current ftview (from the git repository, but rather the same as with version 2.4.5) with valgrind on my GNU/Linux box, I get a bunch of Conditional jump or move depends on uninitialised value(s) but nothing else (and I'll fix these problems in due course). I must admit that I'm rather poor at understanding such exploits, but AFAIK, a conditional jump can't be abused for executing arbitrary code, right? Please correct me if I'm wrong. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] details on iPhone exploit caused by FreeType?
has anyone more information on the recent exploit for the iPhone, reportedly caused by a problem within FreeType's `t1_decoder_parse_charstrings'? Extracting the buggy font from http://www.jailbreakme.com/saffron/_/iPod_4.3.3_8J2.pdf and testing the current ftview (from the git repository, but rather the same as with version 2.4.5) with valgrind on my GNU/Linux box, I get a bunch of Conditional jump or move depends on uninitialised value(s) but nothing else (and I'll fix these problems in due course). I've applied the fix below, rejecting negative arguments to `callothersubr'. This corrects the valgrind errors. If you think that this is a critical issue (this is, if the exploit is repeatable with FreeType 2.4.5 and my patch fixes this), I'll release 2.4.6 as soon as possible. Please test and comment. Werner == diff --git a/ChangeLog b/ChangeLog index 25fb10c..c58d6bf 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2011-07-08 Werner Lemberg w...@gnu.org + + [psaux] Add better argument check for `callothersubr'. + + * src/psaux/t1decode.c (t1_decoder_parse_charstrings) + op_callothersubr: Reject negative arguments. + 2011-07-07 Werner Lemberg w...@gnu.org [sfnt] Try harder to find non-zero values for ascender and descender. diff --git a/src/psaux/t1decode.c b/src/psaux/t1decode.c index ea31c51..a60ec38 100644 --- a/src/psaux/t1decode.c +++ b/src/psaux/t1decode.c @@ -4,8 +4,7 @@ /* */ /*PostScript Type 1 decoding routines (body). */ /* */ -/* Copyright 2000-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009*/ -/*2010 by */ +/* Copyright 2000-2011 by */ /* David Turner, Robert Wilhelm, and Werner Lemberg. */ /* */ /* This file is part of the FreeType project, and may only be used, */ @@ -687,6 +686,9 @@ subr_no = (FT_Int)( top[1] 16 ); arg_cnt = (FT_Int)( top[0] 16 ); +if ( arg_cnt 0 || subr_no 0 ) + goto Unexpected_OtherSubr; + /***/ /* */ /* remove all operands to callothersubr from the stack */ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] details on iPhone exploit caused by FreeType?
I would have this check under default: on line 1013 because other cases have good checks already. But the `default' label continues, while `Unexpected_OtherSubr' aborts... That default is rather strange: wish me luck. Really? :-) Obviously, you aren't aware of TeX's warning messages like I've inserted a begin-math/end-math symbol since I think you left one out. Proceed, with fingers crossed. If you process the PDF used as the iPhone exploit with acroread, you actually get a visible result inspite of the buggy font! In other words, acroread is extremely fault-tolerant. However, it's luck IMHO whether the PS font engine can continue or not. Ideally, FreeType's PS engine should try to be fault-tolerant too. For example, in case of negative arguments to `callothersubr' it is possible to simply ignore the opcode and its two arguments. For the moment, I've decided to abort. Patches to improve this are highly welcomed. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] details on iPhone exploit caused by FreeType?
Moving error check down to default, where it belongs Applied, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
I've been working on a bug for webkit related to an odd behavior with the Ahem font in the Qt framework. I tracked it down to Qt either receiving incorrect descent/ascent values from FT_Size_Metrics or using the Freetype library incorrectly. Within TrueType fonts, there are three sets of global descent/ascent values for historical reasons. Normally, FreeType uses the ascender/descender values from the `hhea' table; this seems to work in most cases. However, the `OS/2' table holds two other sets, and it is easily possible that your font contains strange values within `hhea'. A few days ago I've applied a patch which makes FreeType use the values from `OS/2' in case the `hhea' values are both zero. When using FT_Set_Char_Size(face, width, height, h_res, v_res), should face-size-metrics have the proper values for all font types afterwards or is it necessary for Qt to handle knowing truetype fonts use ((TT_Size)face-size)-root.metrics instead? The former. But due to the problematic definition of the global ascender and descender in TTFs, FreeType might give wrong results. If face-size-metrics is supposed to have proper values after calling FT_Set_Char_Size, then there is a bug in either ttdriver.c or ttobjs.c. ttdriver.c line 248: if ( FT_IS_SCALABLE( size-face ) ) error = tt_size_reset( ttsize ); will need to copy ttsize-metrics over to ttsize-root.metrics or ttobjs.c line 1057: metrics = size-metrics; will need to be metrics = size-root.metrics; are some potential fixes. IIRC, we had such code a few years ago, and it has been reverted for reasons I currently don't remember. Can you privately send me the problematic font for further investigation? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
I've been working on a bug for webkit related to an odd behavior with the Ahem font in the Qt framework. I tracked it down to Qt either receiving incorrect descent/ascent values from FT_Size_Metrics or using the Freetype library incorrectly. When using FT_Set_Char_Size(face, width, height, h_res, v_res), should face-size-metrics have the proper values for all font types afterwards or is it necessary for Qt to handle knowing truetype fonts use ((TT_Size)face-size)-root.metrics instead? BTW, right after a call to FT_Set_Char_Size, `face-size-metrics' and `(TT_Size)face-size)-root.metrics' point to the same object... You probably mean something different? If face-size-metrics is supposed to have proper values after calling FT_Set_Char_Size, then there is a bug in either ttdriver.c or ttobjs.c. ttdriver.c line 248: if ( FT_IS_SCALABLE( size-face ) ) error = tt_size_reset( ttsize ); will need to copy ttsize-metrics over to ttsize-root.metrics or ttobjs.c line 1057: metrics = size-metrics; will need to be metrics = size-root.metrics; are some potential fixes. This is a difficult issue. The question is what `proper values' actually mean. From the documentation for FT_Size_Metrics: Note that due to glyph hinting, these values might not be exact for certain fonts. Thus they must be treated as unreliable with an error margin of at least one pixel! Normally, FreeType does grid-fitting of metrics (cf. the stuff guarded by the GRID_FIT_METRICS macro in ftobjs.c's ft_recompute_scaled_metrics) using FLOOR and CEIL if hinting is requested for, regardless of the font format. For TrueType fonts, this gets replaced internally with ROUND if the font asks for it (in tt_size_reset). This explains the one-pixel difference you experience sometimes. Mhmm. Perhaps the rounding code in `tt_size_reset' should be executed only if GRID_FIT_METRICS is undefined? The metrics values actually *are* already rounded to integers... Chia-I, can you comment also? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] details on iPhone exploit caused by FreeType?
What do you know about this one: CVE-2011-1908? Nothing. Is this the same issue or an older one? I don't know. Nobody has contacted me recently. Some months ago, people from Foxit have sent a bunch of problems which I've tried to fix in the git repository (thus all related patches are in version 2.4.5). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fw: iphone exploit in freetype
This is what I've received from Dirk as an answer. No idea what version of FreeType the iPhone people use... Werner ---BeginMessage--- Hi Werner, somebody pointed me at your question on the mailing list. I strongly believe that the issue was somehow fixed or mitigated by this commit: commit 6b3d00e1a0bc5033aeeab51912eda0aff6ed6e8b Author: Werner Lemberg w...@gnu.org Date: Tue Feb 3 21:34:29 2004 + * src/type1/t1load.c (parse_dict): Handle `RD' and `-|' commands outside of /Subrs or /CharStrings. This can happen if there is additional code manipulating those two arrays so that FreeType doesn't recognize them properly. which has been added in freetype 2.1.8. I can replicate a crash with 2.1.7 (and it is fixed with this one patch), and it works for me as well for 2.1.8 and beyond. Hope this helps. Greetings, Dirk ---End Message--- ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
I've made a patch for the proposed change below. Please let me know if anything needs to be adjusted. The patch looks good, thanks. Just for the record, please give some numeric values for your problem with the Ahem font so that I can identify and handle potential issues in the future more easily. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] details on iPhone exploit caused by FreeType?
Here's the answer from Matthias. 1) Fix2Int does shift before conversion. How does it solve the undefined behavior with negative numbers? After the shift, the upper half is undefined. The cast to Short cuts off the upper half, and the following cast to Int does the sign extension in a defined manner. 2) Why not (FT_Int)(FT_UInt)? This wouldn't work. What one could do is to do the sign extension manually: Int result; result = (UInt)(f) 16; if (result 8000) result |= 0x; 3) Is Fix2Int conversion shared with other parts of freetype? No. The 16.16 fixed-point format is postscript specific. I only checked within the psaux directory and didn't find uses besides the ones covered by the patch. best regards Matthias ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
For reference if anyone is curious, any pixel size that is not a multiple of 5 will exhibit the problem. A couple common ones are 72px and 96px which should be a 72x72 and 96x96 respectively. Leading is 0 for Ahem so height should be ascent+descent. $BUU$(Q.-(B I've applied your patch. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] building freetype without gzip and bzip2 fonts
I'd like to build a static library version of Freetype2 that does not link in libgz or libbz2. May I assume that disabling support for gzip and bzip2 compressed fonts would do that? How would I disable this? If you say ./configure --help you can see this, among other information: Optional Packages: --without-zlib use internal zlib instead of system-wide --without-bzip2 do not support bzip2 compressed fonts If you want to suppress support for LZW and GZIP completely (this is, not using FreeType's internal modules for those two compression methods), undefine the corresponding macros in ftconfig.h Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint 0.2 has been released
ttfautohint 0.2 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/project/freetype/files/ttfautohint Enjoy! Werner -- This project provides a library which takes a TrueType font as the input, remove its bytecode instructions (if any), and return a new font where all glyphs are bytecode hinted using the information given by FreeType's autohinting module. The idea is to provide the excellent quality of the autohinter on platforms which don't use FreeType. The library has a single API function, `TTF_autohint'; see `src/ttfautohint.h' for a detailed description. Note that the library itself won't get installed currently. A simple command-line interface to the library is the demo program `ttfautohint'; after compilation and installation, say ttfautohint --help for usage information, or say man ttfautohint to read its manual page. -- New in 0.2: * Fix bytecode bugs which prevented correct rendering on some platforms. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft-announce] ttfautohint 0.2 has been released
ttfautohint 0.2 has been released. It is available from http://savannah.nongnu.org/download/freetype/ both these links seem to be 404 errors, :-/ Don't miss the small print on that page :-) Downloads will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use http://download-mirror.savannah.gnu.org/releases/ http://sourceforge.net/project/freetype/files/ttfautohint Aargh! I did it again! I've missed an `s'. It should be http://sourceforge.net/projects/freetype/files/ttfautohint instead. Sorry for that. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] - Add FT_DISABLE_STREAM_SUPPORT to disable the use of file streaming functions for memory savings
Here is an updated version and a changelog entry. I'm not sure if I'm 100% happy with the wording of the option comment though. Please let me know if there are other changes that I should make here. Thanks. I've modified your patch to bring it in line with the conventions of FreeType. Especially the formatting used in the ChangeLog file is, hmm, slightly different :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] broken hinted DejaVuSans et 4
This is NOT a recent regression and should not hold 2.4.6. But why is the attached so ugly? A very good question! Fortunately, you shouldn't see this in real life if applications properly follow the data in the `gasp' table. ftview 4 /usr/share/fonts/dejavu/DejaVuSans.ttf and toggle 'h' a couple of times. Make sure that you play at size 4. This is DejaVu 2.33. I've tested with version 2.25, and I can get the erratic behaviour even without pressing a key by using ftview -f 3978 4 DejaVuSans.ttf (glyph index 3978 corresponds to glyph `uni277C') but not with ftview -f 3979 4 DejaVuSans.ttf It seems that the execution of this glyph's bytecode at that size somehow influences rendering of other glyphs, but I have no idea how this is possible at all. Valgrind shows nothing, BTW. This needs a detailed investigation, single stepping through the bytecode with the C debugger, and I don't have enough time currently to that. Please file a bug report. Thanks for bringing this weird behaviour to our attention. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] details on iPhone exploit caused by FreeType?
I sent privately to Werner yesterday, but since the sites are public, I guess it might as well go to the full list. [...] And I replied that I'll do a new release today :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
Werner, you are right, it should be reflected in the CHANGES. The changes result in better, more consistent line spacing. DejaVu got one point smaller, there is nothing wrong with that too. Done. Thanks for the images! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType 2.4.6 has been released
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
[ft-devel] The smallest font
Here's a link to a really fascinating article on creating a smallest TrueType font. I've enjoyed it a lot! http://processingjs.nihongoresources.com/the_smallest_font/ Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A few tiny patches
Here's a small set of patches I'd like to get in to the official tree. [...] Thanks! Let me know if you have any questions or need more info. Please send me the broken fonts privately which trigger the problems. I collect such beasts :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] homepage for ttfautohint
This might be interesting to you: http://www.freetype.org/ttfautohint Enjoy! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Regarding the freetype (OSS)
We are considering using your program “freetype 2.3.5” in our products. This is a quite old version. I recommend the current one, 2.4.6. Before going any further, however, we would like to confirm the following so that we are sure to fully respect your rights. You are the author and owner of the copyrights in the program. You have distributed the program under the attached license The file you have attached is not the license. Please look into LICENSE.TXT. that permits us to use and redistribute the program with or without modification provided that any conditions stated in the license are met. I confirm this. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_New_Memory_Face crashes
Louis, your attachment is too big for the mailing list. Additionally, it contains a non-free font which is not allowed to be distributed. Please resend it without the font, if necessary, and I'll forward your mail to the list. BTW, trying to compile with g++ -o Standalone \ -O0 -g \ Standalone.cpp \ -I /usr/local/include/freetype2/include \ -L /usr/local/lib \ -lfreetype I get this: Standalone.cpp:6:43: error: ‘zip_uint64_t’ has not been declared Indeed, `zip_uint64_t' is not defined anywhere in your bundle, thus I can't proceed. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_New_Memory_Face crashes
The main difference between the standalone and Android app is the
way that the input TTF file is read in, however I verified that my
TTF file is read in correctly in Android, by writing out the buffer
that I read in to a new file, and then comparing the original with
this - they are identical.
What about putting the font into a static buffer, this is, converting
the font into something like this:
const char* font = { 0x01, 0x05, 0x03, ... }
This could eliminate one possible source of error.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint 0.3 has been released
ttfautohint 0.3 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ttfautohint Enjoy! Werner PS: Downloads from savannah.nongnu.org will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use http://download-mirror.savannah.gnu.org/releases/ -- This project provides a library which takes a TrueType font as the input, remove its bytecode instructions (if any), and return a new font where all glyphs are bytecode hinted using the information given by FreeType's autohinting module. The idea is to provide the excellent quality of the autohinter on platforms which don't use FreeType. The library has a single API function, `TTF_autohint'; see `src/ttfautohint.h' for a detailed description. Note that the library itself won't get installed currently. A simple command-line interface to the library is the demo program `ttfautohint'; after compilation and installation, say ttfautohint --help for usage information, or say man ttfautohint to read its manual page. -- New in 0.3: * Fix font generation; sometimes the `glyf' table was one byte too short, making the font invalid. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] broken hinted DejaVuSans et 4
This means that FreeType is fine and DejaVuSans's hinting at 4ppm is buggy. :-) Due to the `gasp' table, this is a non-issue anyway. It cannot be both non-issue and buggy font. The hinting at 4ppem *is* buggy. However, the gasp table prevents hinting at this size, for exactly that reason. So it is a non-issue. No blame for ftview and its handling of gasp? ftview intentionally doesn't handle gasp. Instead, you can manually switch on and off the various hinting and rendering modes. I've examined the issue more closely because such rendering artifacts look fishy; there was a possibility that the bug lies within FreeType. It's a relieve for me that everything is OK. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Load_Char behavior when glyph not present
What is the expected behavior of FT_Load_Char when the requested glyph is not present in the font file? One user of freetype-py (http://code.google.com/p/freetype-py/) reported that freetype returns no error (and does not load the glyph obviously). FT_Load_Char is always successful (provided the font is valid and there is a charmap). For character codes without a `real' glyph, the `undefined' glyph is returned. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype2 - Install issues under Linux SUSE SLES 11 SP1
cannot find -lz This dependency is from FreeType itself. Say ./configure --without-zlib to use FreeType's LZW implementation. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] move band check outside of the loop.
This is a final version of the patch that optimizes both conic and cubic flatteners. Polished and tested. Please consider. Sorry for the long delay. It looks good I've applied it to the git repository, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_Kerning returns 0
I check if my TTF file has kerning information using FT_HAS_KERNING, and this returns true. I then use: FT_Get_Kerning(face, prev, next, FT_KERNING_DEFAULT, delta); to determine the kerning value, but delta.x returns 0. How can I debug why the kerning value is 0 even though FT_HAS_KERNING returns true? Don't assume that there is a kerning value for all glyph pairs! Use a program like `ttx' (sourceforge.net/projects/fonttools/) to get a dump of a TrueType font. Then check whether there is a kerning value between the two particular glyphs. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] character spacing
Also - as I have already invested much time in Freetype I no longer have time to integrate a different library such as Pango - is there somewhere I can obtain freely distributable TTF files that contains kerning information that can be handled by Freetype? If a font doesn't contain a `GPOS' table and only `kern', you are on the safe side. This inspection can be done even manually; just search for `GPOS' inside the font (rather at the beginning, within the first few kBytes). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] character spacing
My original problem persists though and there is too much spacing between certain characters, such as F and a, and between 1 and almost any other number. Is this not something that should be dealt with by the kerning table, or do I now need to look for a different font? I think that your problem is not related to kerning at all. Do you use sub-pixel positioning? Perhaps it really helps if you compare your code to one of the ftdemo programs. Besides that, I'm running out of ideas. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Set_Char_Size()
If any one could answer my (silly?) question. I need to use FT_Set_Char_Size() to set my character size at point 7,25 (verdana). Since this function accepts FT_F26dot6 as the char height and width, I am wondering how I can set point 7,25 without losing data if I cast 7,25 to FT_F26dot6. As the name says, F26dot6 has 26 bits before the dot, and 6 bits after it. Consequently, you simply multiply by 64 if you want to convert into the F26dot6 format: 7.25 * 64 = 464 Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_Char, FT_Get_Next_Char
Using the following code with the attached (very small) font: No font attached. BTW, never ever send complete non-free fonts to this list! Small, subsetted ones are OK. I'm getting the following output: Num glyphs: 3 char: 32 (index = 1) char: 160 (index = 1) How do I get the last char ? (or did I do something wrong ?) Without seeing the font this can't be answered. For example, character code 160 might map to the `space' glyph, having glyph index 1 also. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_Char, FT_Get_Next_Char
I'm getting the following output: Num glyphs: 3 char: 32 (index = 1) char: 160 (index = 1) How do I get the last char ? (or did I do something wrong ?) Without seeing the font this can't be answered. For example, character code 160 might map to the `space' glyph, having glyph index 1 also. The actual question was related to the number of glyphs (3) and the use of first/next char. Am I not supposed to be able to get all glyphs using them? Obviously I only get 2 of them while I would have expect 3. I think this is a bug in FreeType. This font has three glyphs: 0 .notdef 1 space 2 a77 If you use `ftdump -v' (from a recent FreeType version), you can see this: charmaps 0: platform 3, encoding 1, language 0 (active) 0x0020 = 1 0x00a0 = 1 1: platform 7, encoding 2, language 0 0x0020 = 1 0x0074 = 2 Platform/encoding pair (3,1) is Unicode, (7,2) is Adobe custom encoding. Only the latter is contained within the font, the Unicode charmap gets synthesized by FreeType. And here is the problem: The glyph with name `a77' has a canonical mapping to Unicode character U+25BC (as can be seen in file `zapfdingbats.txt' from the Adobe Glyph List), but FreeType doesn't handle zapfdingbats.txt; this is an oversight. Note, however, that in subsetted CFFs (as part of PDF files) you normally have a lot of glyphs which can't be accessed by Unicode character codes. If you are going to handle PDF files, you *must* work with glyph names. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Load_Glyph FT_LOAD_IGNORE_TRANSFORM
Sorry for the late response. I'm trying to figure out if the following two snippets of code will load the glyph in the same way in all cases... Snippet#1: --- FT_Set_Transform(face, NULL, NULL); FT_Load_Glyph(face, glyph_index, load_flags); Snippet#2: --- FT_Load_Glyph(face, glyph_index, load_flags | FT_LOAD_IGNORE_TRANSFORM); I question this because FT_Load_Glyph uses the following logic when determining if auto-hinting should be used: [...] The decision is based on the transformation matrix without considering if the FT_LOAD_IGNORE_TRANSFORM bit is set. Is this a bug? Does the glyph always get loaded the same way in both cases? This really looks like a bug. Can you provide a fix? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Load_Glyph FT_LOAD_IGNORE_TRANSFORM
The decision is based on the transformation matrix without considering if the FT_LOAD_IGNORE_TRANSFORM bit is set. Is this a bug? Does the glyph always get loaded the same way in both cases? This really looks like a bug. Can you provide a fix? Here is a patch. :) Applied, thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Load_Glyph bugs?
[...] maybe someone meant the following? /* apply `standard' transformation if no renderer is available */ if ( internal-transform_flags 1 ) FT_Outline_Transform( slot-outline, internal-transform_matrix ); if ( internal-transform_flags 2 ) FT_Outline_Translate( slot-outline, internal-transform_delta.x, internal-transform_delta.y ); Yep. Applied, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
