[ft-cvs] freetype2/objs .cvsignore
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Werner LEMBERG [EMAIL PROTECTED] 06/04/01 04:43:11 Modified files: objs : .cvsignore Log message: Updated. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/objs/.cvsignore.diff?tr1=1.2tr2=1.3r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2/objs .cvsignore
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Werner LEMBERG [EMAIL PROTECTED] 06/04/01 04:57:06 Modified files: objs : .cvsignore Log message: Updated. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/objs/.cvsignore.diff?tr1=1.3tr2=1.4r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ./ChangeLog builds/unix/install.mk
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Werner LEMBERG [EMAIL PROTECTED] 06/04/01 05:22:07 Modified files: . : ChangeLog builds/unix: install.mk Log message: * builds/unix/install.mk (uninstall): Don't handle `cache' directory which no longer exists. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1290tr2=1.1291r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/builds/unix/install.mk.diff?tr1=1.25tr2=1.26r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
Re: [ft] Type 1 PFM read problem.
Perhaps we should allow both `0x' and `0x0100' as the starting bytes and wait until users complain. I got a report privately that MS Windows accepts values in the range 0x-0x03FF for the first two bytes (found out by try-and-error). Werner ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
[ft] Half-curve, em size
Hello, all, Two small questions, if you permit. Is it acceptable (i.e. not breaking any convention) to define two straight lines connected by a curve, like these in snapshot.png, by skipping one of the straigth lines and using half of the curve instead, as in snapshot1.png? If so, will that have any negative effects, like slower or lower quality rendering? Will breaking the convention of em being a power of 2 for TrueType fonts have any such negative effects? TNXADV. -- E-gards: Jimmy snapshot.png Description: PNG image snapshot1.png Description: PNG image ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
[ft-devel] rounding bug in MS TT rasterizer
Sergej, Paul, from time to time we from the FreeType team get reports that our engine doesn't rasterize certain TrueType glyphs correctly. The most noticeable and disturbing case is glyph `W' in the font `arialuni.ttf' (see attached image). Careful inspection has shown that the very problem here (and in other cases) is a rounding bug in the MS rasterizer which the bytecode instructions of arialuni.ttf explicitly circumvent. Rogier van Dalen writes: I see the very same asymmetry on my rasterizer. Point 25 is the problematic point. I've calculated it all; Microsoft rounds the x-coordinate 895.455782 up to 896 (14.0) in an interpolate instruction. It is then rounded to half a pixel, to 14.5 according to the MS interpreter, to 13.5 according to FreeType's and mine. A delta instruction then moves it left to 13.5 (12.5). To conclude, the MS rasterizer does faulty rounding here, and a delta instruction could have been spared if they had implemented it properly. I'm quite sure that this rounding bug has historical roots and won't be fixed -- many, many fonts would render worse. This means that we have to emulate the behaviour of the MS rasterizer to get `correct' results. Can you tell us more about this problem? Which instructions are affected? What exactly is the reason for the incorrect rounding? Since so many fonts rely on this `feature' it should be documented -- ideally in the TrueType specification. Werner PS: I wonder whether Apple's rasterizer renders this glyph similar to MS Windows... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] OpenType Layout code revisited
Hi, Last night I restructured and cleaned up the OpenType Layout code (from FreeType1) that has been in Pango and import it into a new repository under the name HarfBuzz on fd.o. You can browse the code or join the mailing list here: http://freedesktop.org/wiki/Software/harfbuzz It contains the OTL buffer object that Owen developed too. Lars Knoll has already shown interest in reusing this version in Qt, and Pango is using a copy of it that I'll keep in synch. Comments and suggestions are welcome :). --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fw: [OpenType] Re: rounding bug in MS TT rasterizer
I got this interesting answer from MS. Werner ---BeginMessage--- OpenType list address: [EMAIL PROTECTED] Hi Werner, This sort of thing happens all the time in the TrueType rasterizer, and it relates to precision and the order of operations. In the particular example below, the x value of point 25 is 9.5 (608), and the interpolate instruction wants us to add 4.4978769 to it. With the 26.6 fixed point precision of the TrueType rasterizer, 4.4978769 is represented as 4.5. When added to the 9.5 we get 14 (896). Since we are rounding to half grid, the following MDAP rounds us to 14.5, which then gets DELTA'd to 13.5. I don't consider this a bug nor incorrect, the TrueType hinting engine is consistent in how it deals with rounding and precision. In the Microsoft implementation of the TrueType rasterizer we based the definitions of precision and rounding _in the interpreter_ on the code originally developed by Sampo, Mike Reed, al. at Apple. Microsoft did make some changes in how we scan converted quadratic Beziers, which did lead to some pixel differences, but we considered that acceptable. Other changes, such as dealing with composite transforms have been synchronized with Apple. I see the TrueType specification as a font creator's guide and not an implementation guide. The later would take a significant amount of time to document. Greg Werner LEMBERG wrote: Sergej, Paul, from time to time we from the FreeType team get reports that our engine doesn't rasterize certain TrueType glyphs correctly. The most noticeable and disturbing case is glyph `W' in the font `arialuni.ttf' (see attached image). Careful inspection has shown that the very problem here (and in other cases) is a rounding bug in the MS rasterizer which the bytecode instructions of arialuni.ttf explicitly circumvent. Rogier van Dalen writes: I see the very same asymmetry on my rasterizer. Point 25 is the problematic point. I've calculated it all; Microsoft rounds the x-coordinate 895.455782 up to 896 (14.0) in an interpolate instruction. It is then rounded to half a pixel, to 14.5 according to the MS interpreter, to 13.5 according to FreeType's and mine. A delta instruction then moves it left to 13.5 (12.5). To conclude, the MS rasterizer does faulty rounding here, and a delta instruction could have been spared if they had implemented it properly. I'm quite sure that this rounding bug has historical roots and won't be fixed -- many, many fonts would render worse. This means that we have to emulate the behaviour of the MS rasterizer to get `correct' results. Can you tell us more about this problem? Which instructions are affected? What exactly is the reason for the incorrect rounding? Since so many fonts rely on this `feature' it should be documented -- ideally in the TrueType specification. Werner PS: I wonder whether Apple's rasterizer renders this glyph similar to MS Windows... Subscribe: [EMAIL PROTECTED] Unsubscribe: [EMAIL PROTECTED] Set list to inactive: [EMAIL PROTECTED] Set list to active: [EMAIL PROTECTED] Message mode: [EMAIL PROTECTED] Digest mode: [EMAIL PROTECTED] ---End Message--- ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [OpenType] Re: rounding bug in MS TT rasterizer
Greg, thanks a lot for your answer! In the particular example below, the x value of point 25 is 9.5 (608), OK. and the interpolate instruction wants us to add 4.4978769 to it. Hmm. I get the value 4.4914966. The locations of the involved points right before the IP instruction are original x value of reference point 1: 606 ( 9.46875) [O1] original x value of reference point 2: 1194 (18.65625) [O2] current x value of reference point 1: 608 ( 9.5) [C1] current x value of reference point 2: 1216 (19.00) [C2] original x value of point 25: 884 (13.8125) [OX] C2 - C1 608 - --- * (OX - O1) = --- * 278 O2 - O1 588 Where's the difference? In case there aren't differences, how do you compute this term? With the 26.6 fixed point precision of the TrueType rasterizer, 4.4978769 is represented as 4.5. When added to the 9.5 we get 14 (896). Since we are rounding to half grid, the following MDAP rounds us to 14.5, which then gets DELTA'd to 13.5. We do exactly the same. I don't consider this a bug nor incorrect, the TrueType hinting engine is consistent in how it deals with rounding and precision. Well, there must be a problem before the IP instruction... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
