Re: [Devel] 'tension' in splines, Hermite Splines [Re: Rendering (by FreeType) and hinting of Latin small 'a']

[Vadim Plessky]

On Thursday 12 September 2002 6:04 am, David Turner wrote:
|  I again Vadim,
|
|  Vadim Plessky wrote:
|  > Further search for Hermite Splines provided several quite interesting
|  > links. [1] http://www.cubic.org/~submissive/sourcerer/hermite.htm
|  > [2] http://patrick.wagstrom.net/projects/cs411/prog4/
|  > [3]
|  > http://www.siggraph.org/education/materials/HyperGraph/modeling/splines/
|  >hermite.htm
|  >
|  > Author of [2] has working sample (sources also available) of program
|  > which draws different splines - Hermite, Cardinal, Bezier.
|  > pre-compiled binary (for RedHat 7.2) runs ok on my Linux-Mandrake 8.2
|  > Drawing different kinds of splines in that program is a lot of fun :-)
|
|  I dont think that Hermite splines have any kind of use in our case.
| They're much more complex to process and render than cubic or quadratic
| beziers, so forget about real-time processing. And I don't see how we could

Well, I have checked today, with help of TtfMod, complexity of so-called 
"well-hinted TrueType fonts". In particular, Times New Roman TTF.
And I can tell you that level of complexity I found, far exceeded my 
expectations!
Here are some numbers illustrating TNR complexity.
Number is number of instructions, to be precise: instructions+operands, 
executed by interpreter.
And this doesn't include calls to subroutines!

        capital small
A       427     596
B       600
K       575     570
M       448     323
N       393     263
R       446     163
S       598     776
V       428     569
W       679     801
X       673     868
Y       405     303
E       -               578
G       -               740
Cyrillic
Ж       376     410  (Unicode: U+0416)
Ш       311     209  (U+0428)
Щ       336     235  (U+0428)

Returning to samll Latin 'a' - it required 596 bytes (opcode+operands) for 
*right* hinting and good rendering.
I also loaded several fonts (TNT, CG Times, DutchNew, NimbusRoman, Caslon, 
NimbusSans) into FontLab4 and asked it to auto-hint 'a' in TrueType mode.
Results are presented here:
 http://freetype.newmail.ru/misc/tt-hinting-a.html
BTW: can you consider pls adding to ftview/ftstring 'waterfall" mode like on 
these screenshots, right-bottom part?

Depending on outline quality and origin (TTF or PS Type1), FontLab's 
auto-hinter produced from 7 to 15 *high-level* TrueType hints.
I name them high-level, as NimbusRoman and NimbusSans TTF's have 196 and 170 
operations(addresses) for 'a'. At least that's what TtfMod tells me.
So it seems FontLab translates those *high-level* TrueType hints into 
low-level TT opcodes, complements them with stack data, etc.

My point is that 15 operations per glyph are *reasonable*, and can be 
overviewed/hinted by a man (as you can see from URL above, TT auto-hinter 
results in FL4 are acceptable in mnay cases, but need correction by hand)
196 operations, not speaking about 600, can't be coded by a man.

We have following options to provide good (better) rendering:
1) embedded bitmaps (short term solution, IMO)
2) enhanced PostScript renderer
That's a Dream which for some reason doesn't want become True.

I would expand on this.
For 20 years (PostScript development and usage time, I do not count PDL born 
in Xerox PARC here), Adobe was not able to develop PostScript rasterizer (for 
fonts) producing *acceptable* quality.
I especially emphasize on word *acceptable*, I am not speaking about *perfect* 
or *close to perfect*.
This doesn't necessary mean that it's not possible to produce such rasterizer.
And FreeType since 2.0.9 version kicks Adobe's ass, for sure.
But can it be that approach itself is wrong?..
That's what I am trying to ask.
Just let me rememebr that first PostScript printer produced by Apple in mid 
80's had MC68000-8Mhz procesor, and very limited memory (128K?).
Memory and slow processor certanly were serious constrains for further 
development of PostScript language, and good rendering.
Today we can assume that renderer has at least 400Mhz processor, and 32MB of 
RAM (while typical desktop has about 128MB of RAM)
That's a HUGE difference!
And I am wondering why people do not use ray-tracing as font rendering 
technology yet :-)

3) Cubic Bezier splines (PS Outlines) with enhanced/different hinting model.
4) splines/curves of higher order (4th, 5th, etc.)
5) other type of splines - like those Hermite splines, etc.
It's interesting that modified Hermite splines used in 3D Studio Max, which is 
known for producing very good rendering. 
Ok, it's not Alias/Wavefront, or SoftImage, but it's good!

Approach 2) is evolutionary, approach 5) is revolutionary.
Ok, it requires some adoption of code & changes in rendering ideology, but it 
seems font designers who used IKARUS are already familiar with that approach.
And found it usefull (some think-superior to Bezier splines)

So far, I don't like variant 1), 3), 4)

| easily adapt the hinters to work on them. Finally, we'd still need to
| import/export bezier arcs anyway which may introduce some accuracy/rounding
| problems in certain ill cases..

This can be done if font editor, like PfaEdit.
And there are accuracy/rounding problem in TT->PS conversion, anyway.
And this is not the biggest problem, IMO.
Problem is that TrueType outlines have *too many* points, and this *decreases* 
font quality in most cases.

|
|  Also, I don't think that you can interpolate a Hermite spline by simply
|  interpolating its control and vector points, so this adds a tremendous
|  amount of complexity.

Why do you think that  we can't interpolate Hermite spline?
I thought that splines can be *interpolated* by definition.
That's what they were created for :-)

|
|  That's probably a dangerous path to take. Feel free to study them further
|  if you feel so however. One never knows, I simply don't have the courage
| to try to hint TrueType and Postscript fonts with these..
|
|  > I think 'Tension' and 'Continuity' add extra level of semantics to
|  > *ordinary* curve, which AA rasterizer so badly needs to preserve
|  > original shape of the glyph.
|
|  Just to clarify things, the AA rasterizer doesn't need to preserve the
| shape of anything, it simply computes pixel converages. It's the hinters
| that need to distort the outline in ways that are optimized for certain
| display modes, and they mostly work with beziers and linear interpolation

ok, using 'Tension' and 'Continuity' , hinter should do better job with 
outline deformation.
Like: it should increase pixel coverage if tension is high (preserve more 
black space), and blend pixels located close to each other more smoothly (if 
Continuity is high)

It can be, BTW, that we can extract such values from Bezier curves, too.
At least, Tangent point/node (in Bezier/PS Type1 terms) is very close in its 
ideology to the beginning point of hermite spline.

|
|  That doesn't mean that Hermite splines wouldn't be a good idea if used as
|  the basis of vectorial outlines in a new font format; I simply don't see
|  how we can insert them in the current framework without loosing horrible
|  amounts of performance..
|
|  Regards,
|
|  - David Turner
|  - The FreeType Project  (www.freetype.org)
|
|  _______________________________________________
|  Devel mailing list
|  address@hidden
|  http://www.freetype.org/mailman/listinfo/devel

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/