[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft] Modifying/Enhancing the Truetype Interpreter

From: Moony
Subject: Re: [ft] Modifying/Enhancing the Truetype Interpreter
Date: Tue, 23 Mar 2010 22:21:18 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]