Re: [ft] Modifying/Enhancing the Truetype Interpreter
Sorry for not answering earlier; I've missed your mail. > What I was struggling with was why it was necessary to split the > grid into 16 pieces in the x direction, as opposed to simply /not > rounding at all/. Good question. I've asked MS people why the horizontal resolution factor is 16, and they answered that it fitted them best. Please bear in mind that it makes sense to limit the numbers of subpixels on the designer's side so that you can exactly control the glyph's appearance. On the renderer's side there is no such limitation. > There is still something that the MS interpreter does (that isn't > documented in the whitepaper) to snap some stems to the grid. I > can't figure out how to do that without ruining the glyphs though. > (My guess is that they put lots of hard-code in place.) Perhaps it makes sense that you subscribe to the OpenType mailing list, repeating your questions. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Hi Werner, Another thing I'm struggling with is how to detect whether points have been touched in the non-freedom vector direction during deltaps. Do you have any insights into this, Werner? Can you elaborate? What do you want to achieve? I think I've gotten past this problem by looking at other parts of the code. Essentially, I wanted to detect (based on the desription here: http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx ) whether points had been touched in the Y direction. I figured out how to do this with: FT_CURVE_TAG_TOUCH_Y & CUR.pts.tags[point] == 0. Also, I'm still having a hard time understanding the whole 1/16 pixel in the x direction. What's do you mean with a `whole 1/16 pixel'? Sorry, I'm using English colloquialisms. :) You can remove the "whole" part from my sentence. What I was struggling with was why it was necessary to split the grid into 16 pieces in the x direction, as opposed to simply /not rounding at all/. I'm still not sure why this is necessary, other than the possibility that this made sense to MS in how they implemented their TT interpreter code. The freetype code can just *ignore* this grid completely, as far as I can tell. Regardless, I put into my temporary patch a variable called "grid_factor", which lets you define what to use in the X direction- 1px, 1/2px, 1/16px, 1/32px, etc. I've gotten the best results with 1/32 of a pixel, which is really as far as the freetype code can go. I have been working furiously on getting this patch working well with a variety of fonts. I have the patch to a point where it renders most legacy and CT fonts *very well* with subpixel hinting. All bolds and italics look great, and most roman fonts. There is still something that the MS interpreter does (that isn't documented in the whitepaper) to snap some stems to the grid. I can't figure out how to do that without ruining the glyphs though. (My guess is that they put lots of hard-code in place.) I have redesigned the patch so that it now doesn't ingore the x direction in the "move" functions but rather in the "round" functions, as stated in the whitepaper. This *does* produce better results I've found, but it required more conditionals on MIRPs and stuff. I can tell that MS must have hard-coded a bunch of things in their interpreter, like, "if font=verdana, always do DELTAP"... or "If function 72 is an inline delta, ignore it", etc. If I implement the patch as stated in the whitepaper, it breaks fonts. I am in the process now of cleaning up the patch, but I will post it soon. I am completely open to criticism of it, and suggestions of improvement. There may be parts of it that are inefficient and not up to C coding standards, and I would welcome any suggestions on how to make it work the way you would like. My idea is to use #ifdefs to determine whether "grayscale" is enabled, and if so, to use the new method I've developed, otherwise, if grayscale is not enabled, do the old method that works well with bi-level rendering. Does this approach make sense to you? If not, what would you like to see? Thank you! ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Sorry for the late response. > Another thing I'm struggling with is how to detect whether points > have been touched in the non-freedom vector direction during > deltaps. Do you have any insights into this, Werner? Can you elaborate? What do you want to achieve? > Also, I'm still having a hard time understanding the whole 1/16 > pixel in the x direction. What's do you mean with a `whole 1/16 pixel'? > Perhaps doing this helps with the stem-snapping? I don't understand the question right now... Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
While hinting, the four extra phantom points which control the
horizontal and vertical advance width aren't handled specially.
However, they are stored separately (`pp1' to `pp4' in the `TT_Loader'
structure). In ttgload.c, the `TT_LOADER_SET_PP' macro sets them; and
in `compute_glyph_metrics' they are used to set the advance width.
Ah yes... commenting out the setting of the advance width gets past this
issue. Included in latest patch.
Perhaps something along the following:
. Add a no-op FDEF the the FDEF table.
. In `Ins_FDEF', replace the call to `SKIP_Code' with a new function
which additionally checks for interesting patterns. If we have a
match, point to the no-op FDEF instead of the current one.
I temporarily added some hacky code into the FDEF[] function to detect
opcode patterns. One in particular that handles "VacuFormRounds" gets
past a lot of artifact issues with legacy MS and apple fonts. It makes
a lot of them usable anyway. I'm using this current patch of freetype
on my system right now, and I'm very happy with most of the legacy font
rendering in LCD mode.
I think the vertical stem-snapping is going to be the most difficult of
the issues to get past, due to the fact that the whole idea with the
freedom vector (x) is that you want to NOT force it into a position.
Following the TT hints exactly results in a glyph that is too hammered
into a certain spot, but ignoring it completely results in fuzzy
letters. Finding a good medium would be nice, but I'm struggling to
figure out how to do that.
Another thing I'm struggling with is how to detect whether points have
been touched in the non-freedom vector direction during deltaps. Do you
have any insights into this, Werner? Also, I'm still having a hard time
understanding the whole 1/16 pixel in the x direction. Perhaps doing
this helps with the stem-snapping?
This latest patch has the following changes:
- It is a *GIANT slop-fest* that is in no way intended to be proper or
efficient! I'm just trying to get it done conceptually, and then worry
about efficiency, etc.
- VacuFormRound function is detected and disabled, fixing a lot of
artifacts in legacy MS fonts.
- DeltaP is now disabled after iup[x] and iup[y] are called (using some
global variables ;D ), because it seems like deltaps after those
generally results in dents in the outline. The correct way is
supposedly to skip everything but touched points in the non-freedom
direction, but I am still trying to figure out how to do that. The
iup[x] and iup[y] are a rough approximation of the correct way...
- In general, bolds and italics look very nice, because they tend to not
align with stems (or are thick enough to not notice). In most respects,
and on most fonts, I am happier with how this renders them as opposed to
the existing freetype TT interpreter. PPEMs where the vertical stem
width is close to 1 pixel still need some work, IMO.
- On my system at least, I find that changing the light FIR filter to {
32, 48, 102, 48, 32 } makes color fringes much less apparent. YMMV.
- Arial and Times have some issues with the width getting out of control
when I set the project_x to return "1" at all times. If I return "dx"
(the default), it breaks some glyphs on bold fonts (like 0, o, and other
things with parallel vertical stems like h, n, m.). I'm trying to find
the condition to separate these two things but have been unsuccessful so
far.
http://www.infinality.net/files/ttinterp.20100323-1.patch
___
Freetype mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
> Some letters, for instance Arial normal "v" or "X", or bold "s" > appear to have TT instructions that move the right bearing toward > the left, a pixel or so (figured this out with FontForge debug). > This results in "s" or "v" being smashed up against the following > letter at certain point sizes. (see screenshots). Which part of > the ttinterp.c code would control this moving of the right bearing, > in order that we can disable that part? (It appears that the MS > engine got around this problem by keeping instructions on the glyph > in the x-direction, to fit into this smaller space, but IMO, it > looks bad.) While hinting, the four extra phantom points which control the horizontal and vertical advance width aren't handled specially. However, they are stored separately (`pp1' to `pp4' in the `TT_Loader' structure). In ttgload.c, the `TT_LOADER_SET_PP' macro sets them; and in `compute_glyph_metrics' they are used to set the advance width. > Gamma / LCD filtering- I can't answer this question, sorry. Maybe others can help. > FDEFs- > I'm not sure how to approach searching the FDEFs for certain opcode > patterns, in order to disable them. Suggestions? Perhaps something along the following: . Add a no-op FDEF the the FDEF table. . In `Ins_FDEF', replace the call to `SKIP_Code' with a new function which additionally checks for interesting patterns. If we have a match, point to the no-op FDEF instead of the current one. > Vertical stem snapping- > This is a weird one. The MS engine is clearly doing snapping of > vertical stems to fit symmetrically across pixels at certain ppems > (13 - 15?), but other times not (17 - 20?). Perhaps this depends on data in the `gasp' table? Remember that some fonts must be handled differently for certain ppem values (B/W versus anti-aliased rendering). Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Sorry- I said PGM in the last email- I meant "PPM"! On 03/13/2010 03:12 PM, Werner LEMBERG wrote: A nice option to ftview/ftdiff might be png output! WL> Go forth and add it! However, I rather suggest to produce an WL> image in the PGM image format Or ppm, given that each supports sub-pixel. ☺ Yes, I haven't thought of this. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Some issues I'm running into:
Right bearing-
Some letters, for instance Arial normal "v" or "X", or bold "s" appear
to have TT instructions that move the right bearing toward the left, a
pixel or so (figured this out with FontForge debug). This results in
"s" or "v" being smashed up against the following letter at certain
point sizes. (see screenshots). Which part of the ttinterp.c code
would control this moving of the right bearing, in order that we can
disable that part? (It appears that the MS engine got around this
problem by keeping instructions on the glyph in the x-direction, to fit
into this smaller space, but IMO, it looks bad.)
Gamma / LCD filtering-
It looks as if the MS TT engine does a major gamma "correction" after
running its LCD filter. I've gotten results that look very similar by
creating a custom FIR filter { 40, 75, 86, 75, 40 } and then
gamma-correcting in ftdiff to between 1.5 and 2.2. (See screenshots).
I am unable to create a FIR filter that does this all in one step
however. I'm guessing that this is because the FIR filter splits
intensity across pixels, but gamma applies to the whole pixel? Are
there any gamma correction patches out there that can be applied to
ftlcdfil.c to render in such a way, like it does with gamma-correction
in ftdiff? (I know gamma correction is expensive, and ideally shouldn't
be done at the freetype level, but it would still be nice to have the
option, IMO.)
FDEFs-
I'm not sure how to approach searching the FDEFs for certain opcode
patterns, in order to disable them. Suggestions?
Vertical stem snapping-
This is a weird one. The MS engine is clearly doing snapping of
vertical stems to fit symmetrically across pixels at certain ppems (13 -
15?), but other times not (17 - 20?). Yet, the glyphs don't seem as
constrained in the x-direction as they do with the TT-instructed b/w
rasterizer. I guess I'm interested in getting a good balance between
not deforming glpyhs too much (such as in the case of s, v, or w), yet
doing vertical stem alignment under certain circumstances, such as n, m,
h, or u and also leaving enough room for certain glyphs, like v, w,
X, etc. Any thoughts on this?
I like the idea about adding PGM output... seems relatively easy to
implement.
-Moony
Freetype-rendered, using default LCD filter:
http://www.infinality.net/files/arial-default-lcd.png
Freetype-rendered, using custom FIR filter { 40, 75, 86, 75, 40 } and
then gamma-correcting to 1.7:
http://www.infinality.net/files/arial-darkened-gamma-corrected.png
Rendered with WinXP:
http://www.infinality.net/files/arial-cleartype.png
___
Freetype mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
>>> A nice option to ftview/ftdiff might be png output! > > WL> Go forth and add it! However, I rather suggest to produce an > WL> image in the PGM image format > > Or ppm, given that each supports sub-pixel. ☺ Yes, I haven't thought of this. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
> "WL" == Werner LEMBERG writes: >> A nice option to ftview/ftdiff might be png output! WL> Go forth and add it! However, I rather suggest to produce an WL> image in the PGM image format Or ppm, given that each supports sub-pixel. ☺ -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
> A nice option to ftview/ftdiff might be png output! Go forth and add it! However, I rather suggest to produce an image in the PGM image format[*] – you don't need a library for writing such files – which can then be converted to anything else with the Netpbm tools. Werner [*] This is Netpbm's `Portable Gray Map' image format. ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
I think in general, the modern, free, replacement fonts render pretty well. Liberation is also worth checking out. I personally like the shapes of the MS versions, when they render correctly at least, but the open source versions are very well done. Here is a sample of DejaVu bold and regular: http://www.infinality.net/files/dj.png http://www.infinality.net/files/djb.png On 03/11/2010 11:26 PM, James Cloos wrote: Another point is that the demo images you have sent have, IIRC, only been of ms fonts; it is also important to see what the changes do to other fonts. I am particularly interested in how the Deja Vu family changes when rendered in the 8-24 px/em range with your diff applied. And that only covers a few script/language tuples. Many other fonts are similarly important. Perhaps some suggestions can be made? -JimC ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Another point is that the demo images you have sent have, IIRC, only been of ms fonts; it is also important to see what the changes do to other fonts. I am particularly interested in how the Deja Vu family changes when rendered in the 8-24 px/em range with your diff applied. And that only covers a few script/language tuples. Many other fonts are similarly important. Perhaps some suggestions can be made? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Yes, this was more of a "show" than something useful. ;) I'll see if I can whip up something in Imagemagick to do diffs between screenshots (even subpixel). A nice option to ftview/ftdiff might be png output! This is not very useful IMHO. It's too much information. What I would really like to see is a before-after comparison of single fonts, at various pixel sizes. Then it's easy to do blink comparisons. Perhaps you can write a small script which generates such images automatically, perhaps even generating a `diff' image which marks the changed pixels with, say, red. I've used the script below for B/W images; maybe it can be extended accordingly. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
> http://www.infinality.net/files/ttinterp.20100310-1.patch Thanks. Will have a look later. > Screenshot of the patch in action, with various fonts, in WINE > Wordpad. There are artifacts with some fonts / glyphs that will > probably have to have TT function calls disabled in order to render > better: > http://www.infinality.net/files/wine-wordpad-2010-03-10.png This is not very useful IMHO. It's too much information. What I would really like to see is a before-after comparison of single fonts, at various pixel sizes. Then it's easy to do blink comparisons. Perhaps you can write a small script which generates such images automatically, perhaps even generating a `diff' image which marks the changed pixels with, say, red. I've used the script below for B/W images; maybe it can be extended accordingly. Werner == # Compare two B/W PNG image files, producing a `diff' image file which # highlights changed pixels. Identical pixels are in grey, pixels only in # $1 are coloured green, and pixels only in $2 are coloured red. before=`basename $1 .png` after=`basename $2 .png` if test $# -eq 3; then result=$3 else result=$before-$after.png fi # We need `pnmdepth' to normalize the colour values so that arguments to # `ppmchange' are matched after calling `pamcomp'. cat $1 \ | pngtopnm \ | pnmdepth 255 \ | ppmchange black green \ > $before-green.pnm cat $2 \ | pngtopnm \ | pnmdepth 255 \ | ppmchange black red \ > $after-red.pnm pamcomp -opacity=0.5 \ $before-green.pnm \ $after-red.pnm \ | ppmchange rgb:b3/b3/00 gray95 \ | ppmchange rgb:b3/ff/b3 green \ | ppmchange rgb:ff/b3/b3 red \ | pnmtopng \ > $result 2> /dev/null rm $before-green.pnm rm $after-red.pnm # eof ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Werner, I am totally fine with calling this whatever you'd like. "Subpixel hinting" makes sense to me. 2010-03-10: * Changed the function names to end in _sph instead of _ttslight * Added code back in that deals with x, and divided "distance" by 32, instead of ignoring completely. * Removed modifications from the unpatented hinting section * Made ALIGNPTS use _sph, which supposedly doesn't matter, but helps some legacy italics. * A couple other things maybe. Overall not too different from last patch version. http://www.infinality.net/files/ttinterp.20100310-1.patch Screenshot of the patch in action, with various fonts, in WINE Wordpad. There are artifacts with some fonts / glyphs that will probably have to have TT function calls disabled in order to render better: http://www.infinality.net/files/wine-wordpad-2010-03-10.png This looks very promising! A small aside: I'm not really happy about the `slight hinting' phrase; it just happens that the rendering results look more crisp due to the optical resolution increase in the horizontal direction. What about `subpixel hinting' or something into this direction? BTW, don't worry about the unpatented hinting stuff; in May or so the TrueType patents expire, and I'll remove this stuff altogether. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
> Point taken. I changed the function names to end in _ttslight > instead, and the "ENHANCED TT" to "TT SLIGHT HINTING" as that really > is what this is. > http://www.infinality.net/files/ttinterp.20100307-2.patch > > Original patch has been removed. This looks very promising! A small aside: I'm not really happy about the `slight hinting' phrase; it just happens that the rendering results look more crisp due to the optical resolution increase in the horizontal direction. What about `subpixel hinting' or something into this direction? BTW, don't worry about the unpatented hinting stuff; in May or so the TrueType patents expire, and I'll remove this stuff altogether. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Point taken. I changed the function names to end in _ttslight instead, and the "ENHANCED TT" to "TT SLIGHT HINTING" as that really is what this is. http://www.infinality.net/files/ttinterp.20100307-2.patch Original patch has been removed. On 03/07/2010 02:58 PM, Adam Twardoch (List) wrote: Note that ClearType is a Microsoft trademark for their specific implementation of subpixel rendering. You may be safer off without referring to ClearType (an even "CT") in the source code. A. ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Note that ClearType is a Microsoft trademark for their specific implementation of subpixel rendering. You may be safer off without referring to ClearType (an even "CT") in the source code. A. Moony wrote: > Reference: > http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx > > Patch: > http://www.infinality.net/files/ttinterp.20100307-1.patch > > Added / implemented: > - Created variables func_move_ct and func_move_orig_ct; > - Created _ct versions of certain functions which ignore x-direction moves > - Call new functions under various conditions (see patch) > > > Not implemented: > - 1/16 pixel "supersampling" grid in X. Currently just ignoring x > distances in MDAP, MIAP, MDRP, etc. instead. > - A way to detect and disable certain functions, as described in the > whitepaper. > - Most of the "Backwards Compatible" fixes given in whitepaper. > > > Notes: > - I Put "ENHANCED TT" and notes in most places where code was modified. > - Extremely dirty and hacky > - May be completely wrong approach and / or execution > - Looks very good on fonts designed for CT, and fair on legacy italic > fonts, poor for most else > - Any form of assistance by you is welcome! > > > > > ___ > Freetype mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/freetype > > -- Adam Twardoch | Language Typography Unicode Fonts OpenType | twardoch.com | silesian.com | fontlab.net Reporter: "So what will your trip to Ireland look like?" Lech Wałęsa: "I get into a car, then onto a plane, and then the other way around." ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Reference: http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx Patch: http://www.infinality.net/files/ttinterp.20100307-1.patch Added / implemented: - Created variables func_move_ct and func_move_orig_ct; - Created _ct versions of certain functions which ignore x-direction moves - Call new functions under various conditions (see patch) Not implemented: - 1/16 pixel "supersampling" grid in X. Currently just ignoring x distances in MDAP, MIAP, MDRP, etc. instead. - A way to detect and disable certain functions, as described in the whitepaper. - Most of the "Backwards Compatible" fixes given in whitepaper. Notes: - I Put "ENHANCED TT" and notes in most places where code was modified. - Extremely dirty and hacky - May be completely wrong approach and / or execution - Looks very good on fonts designed for CT, and fair on legacy italic fonts, poor for most else - Any form of assistance by you is welcome! ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
>> Good question. I'll ask it on the OpenType mailing list. Here is a long discussion which gives some hints why the resolution is increased by a factor of 16. http://typophile.com/node/62675 Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
I'm very grateful that you take some time to play with these things... Thanks... the biggest thing I have going for me is that I really, really want the end result. Other than that, I'm pretty clueless about freetype and truetype, and know a little bit about fonts and font rendering. I know there are a lot of people (David Turner maybe?) that would know a lot more about how to implement this! Good question. I'll ask it on the OpenType mailing list. Thanks again. ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
>> Nice! Please don't forget to document, probably with screenshots, >> which code changes cause which improvements, and which cause >> degradations. > > I will take screenshots as well as comment (at least temporarily) > the code in the patch. I feel kind of embarrassed posting these > "hacky" patches of ttinterp.c, but I'm sure it can be refined once > all important parts are identified. ;) I'm very grateful that you take some time to play with these things... >> It might be useful also to emulate ClearType `better', >> this is, to use a larger factor for increasing the horizontal >> resolution. > > This is a part I was wondering about. I understand that CT splits a > pixel into 16 horizontal chunks and stuff like RTDG[], RDTG[], > MDAP[R], MIAP[R], etc., all use that grid. However, let's say we > want to increase the horizontal resolution to 32, or 64, or 256... > or infinity? Wouldn't increasing the horizontal resolution to > infinity simply mean /ignoring/ these instructions horizontally? Good question. I'll ask it on the OpenType mailing list. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Nice! Please don't forget to document, probably with screenshots, which code changes cause which improvements, and which cause degradations. I will take screenshots as well as comment (at least temporarily) the code in the patch. I feel kind of embarrassed posting these "hacky" patches of ttinterp.c, but I'm sure it can be refined once all important parts are identified. ;) It might be useful also to emulate ClearType `better', this is, to use a larger factor for increasing the horizontal resolution. Werner This is a part I was wondering about. I understand that CT splits a pixel into 16 horizontal chunks and stuff like RTDG[], RDTG[], MDAP[R], MIAP[R], etc., all use that grid. However, let's say we want to increase the horizontal resolution to 32, or 64, or 256... or infinity? Wouldn't increasing the horizontal resolution to infinity simply mean /ignoring/ these instructions horizontally? (It would also have the added advantage of requiring less processing.) Perhaps I'm not fully understanding what is going on either. Am I making sense? -Moony ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
> Slowly but surely > http://www.infinality.net/files/ttinterp.c.patch Nice! Please don't forget to document, probably with screenshots, which code changes cause which improvements, and which cause degradations. It might be useful also to emulate ClearType `better', this is, to use a larger factor for increasing the horizontal resolution. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Slowly but surely http://www.infinality.net/files/ttinterp.c.patch http://www.infinality.net/files/segoeuii22.png http://www.infinality.net/files/trebucbd12.png http://www.infinality.net/files/segoeui12.png http://www.infinality.net/files/verdana17.png ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Slowly but surely http://www.infinality.net/files/ttinterp.c.patch http://www.infinality.net/files/segoeuii22.png http://www.infinality.net/files/trebucbd12.png http://www.infinality.net/files/segoeui12.png http://www.infinality.net/files/verdana17.png ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
On 02/25/2010 03:35 AM, Werner LEMBERG wrote: I've found that this small hack/patch does amazing things toward a CT-like rendering, when TT interpreter is enabled at compile time: [...] Very nice. Do you plan to invest more time to work on this? Werner I absolutely want to put more time into this, but I can't promise anything due to my current work schedule. Anyone who is interested in this, please feel free to offer help! The goal is CT-like rendering by enhancing / modifying the freetype TT interpreter. Information is here: http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx -Moony ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
> I've found that this small hack/patch does amazing things toward a > CT-like rendering, when TT interpreter is enabled at compile time: > [...] Very nice. Do you plan to invest more time to work on this? Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
I've found that this small hack/patch does amazing things toward a
CT-like rendering, when TT interpreter is enabled at compile time:
--- ttinterp.c.orig 2010-02-23 18:48:43.0 -0600
+++ ttinterp.c 2010-02-23 18:49:16.0 -0600
@@ -1641,7 +1641,7 @@
{
FT_UNUSED_EXEC;
-zone->cur[point].x += distance;
+/*zone->cur[point].x += distance;*/
zone->tags[point] |= FT_CURVE_TAG_TOUCH_X;
}
Fonts that are designed specifically for CT, like Candara, Corbel,
Segoe, etc. look fantastic between 16px and 24px- TT instructing
vertically, and no hinting horizontally. Older ones like Arial and
Verdana also look good, but suffer from more glitches. This is
obviously not a solution, but it's a start!
Obligatory screenshots:
http://www.infinality.net/files/candara-15pt.png
http://www.infinality.net/files/arial-12pt.png
___
Freetype mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
>> And finally, do you have a working ClearType emulation, this is, at >> least tripling the horizontal resolution for calling the bytecode >> interpreter, then compressing the results again for proper subpixel >> positioning? > > No, I do not. I have tinkered with the code a bit, but haven't > really had a chance to sit down and seriously try something. Modifying, say, ftview shouldn't be too hard. I would be glad to incorporate your yet-to-come changes into the git repository, BTW :-) > I was thinking though – is it even necessary to have a resolution to > snap to in the X direction? Currently, FreeType's smooth renderer in the (horizontal) LCD modes hints the fonts at (R,R) resolution, renders at (3R,R), then compresses the horizontal data using a color filter to get (R,R) again. The important step to emulate ClearType – and to see problems with fonts – is to hint at (3R,R) too. If I interpret the ClearType paper correctly, Microsoft uses (16R,R) to get even finer control. I can even imagine that some fonts render badly if you don't use (16R,R) too. Note that FreeType's TrueType interpreter in versions prior to 2.3.10 was buggy if the horizontal and vertical resolutions differed. > In this scenario perhaps grid-fitting to 1/3 pixel in the X > direction would be considered "full hinting" and leaving the X > direction alone entirely would be considered "slight hinting"? The latter is what you currently get with FreeType in the LCD modes. A direct comparison would be very interesting and instructive – one more reason that I ask you to extend ftview (or, perhaps even better, ftdiff). Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
It's not very difficult, I believe. You probably have to add some flags to one of the internal TrueType interpreter structures to store the results of the bytecode signature scanning. Do you have any ideas how many fonts are affected? Which of them are important/well known? Off hand, I know that MS core fonts would benefit from this. (Basically, any TT font that was hinted with B/W rasterization in mind). Redhat Liberation fonts also seem to be hinted with B/W in mind, as they supposed to be metrically compatible with the core web fonts. In my experience, the fonts that are already "optimized" for CT don't suffer nearly as badly. And finally, do you have a working ClearType emulation, this is, at least tripling the horizontal resolution for calling the bytecode interpreter, then compressing the results again for proper subpixel positioning? No, I do not. I have tinkered with the code a bit, but haven't really had a chance to sit down and seriously try something. I was thinking though- is it even necessary to have a resolution to snap to in the X direction? In this scenario perhaps grid-fitting to 1/3 pixel in the X direction would be considered "full hinting" and leaving the X direction alone entirely would be considered "slight hinting"? ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
>> Do you have any ideas how many fonts are affected? Which of them >> are important/well known? > > Apart from the obvious [...] Perhaps there is a misunderstanding. Do you say that all those fonts won't render OK if I simply, say, triple the horizontal resolution? `Optimized for ClearType' is not the same as `renders badly due to certain hinting instructions if the horizontal resolution is much, much larger than the vertical one'. I'm mainly interested in fonts which belong to the latter category. Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
Werner LEMBERG wrote: > Do you have any ideas how many fonts are affected? Which of them are > important/well known? Apart from the obvious (the Microsoft "ClearType Collection", i.e. Cambria, Corbel, Candara, Consolas, Calibri, Constantia as well as Meiryo for Japanese, Malgun Gothic for Korean, Microsoft YaHei for Chinese Simplified and Microsoft JhengHei for Chinese Traditional), also Microsoft's Gabriola (which ships with Windows 7) plus FontFont's recent "Offc" releases [1], FontShop Germany's Axel [2], a number of fonts released by Ascender (though I have no specific data which ones) [3]. Other font vendors are also working on fonts optimized for ClearType. I assume that you're familiar with the MS whitepaper on ClearType [4]? Please keep in mind that the OpenType spec now includes the head.flags bit 13 which indicates whether a font has been "optimized for ClearType". Best, Adam [1] http://www.fontshop.com/blog/?p=1286 [2] http://www.fontshop.be/details.php?entry=386 [3] http://www.ascenderfonts.com/foundry/ascender/ [4] http://www.microsoft.com/typography/cleartype/TruetypeCleartype.aspx -- Adam Twardoch | Language Typography Unicode Fonts OpenType | twardoch.com | silesian.com | fontlab.net Reporter: "So what will your trip to Ireland look like?" Lech Wałęsa: "I get into a car, then onto a plane, and then the other way around." ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Modifying/Enhancing the Truetype Interpreter
> I'm interested in using the details described in this whitepaper to > make a patch (official or unofficial, don't care) to enhance the > existing TT interpreter in Freetype. The enhanced TT interpreter > would probably be most useful with AA or subpixel, but not with B/W, > where the existing TT is preferable. Essentially it would modify > the TT interpreter to ignore DELTAP instructions in the X direction > under various conditions. Please go ahead! This is definitely a good idea to try. > * Is anybody with more knowledge / experience with TT instrucing / > Freetype willing to attempt to implement this enhanced TT > interpreter? Sorry, I have no time to do that. > * How difficult of a problem is this? Is this feasible? It's not very difficult, I believe. You probably have to add some flags to one of the internal TrueType interpreter structures to store the results of the bytecode signature scanning. Do you have any ideas how many fonts are affected? Which of them are important/well known? And finally, do you have a working ClearType emulation, this is, at least tripling the horizontal resolution for calling the bytecode interpreter, then compressing the results again for proper subpixel positioning? Werner ___ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
