Date: Tue Feb 06 2007 - 18:45:26 CST
I have tried two ways:-
(1) using some default transformations in fontforge
(2) transforming the paths themselves -- by converting a public
license ttf font to svg in which case one can manipulate the Bezier
quadratics (also called spline curves).
Doing it block style with no overlapping is rather like Korean, to get
better results one needs some how to calculate the shortest distance
between the parts and use this to adjust the relative positions, this
means that the boxes sometimes need to over lap when the parts
themselves do not. I have only done this part by hand, if anyone knows
of existing tools/code that will do this then please let me know.
These however do not address the way certain strokes expand or
contract to fill a space eg Òä and ¶² , admittedly many Chinese fonts
also have not addressed this issue, though most manage a different
sized kouzi pang depending the shape of the other part eg Å¶ ß¶ ³ª .
Some of the ideas below are in Richard Cooks / Wenlin's CDL scheme
Quoting Philippe Verdy <firstname.lastname@example.org>:
> From: <email@example.com>
>> I have tried to do this automatically -- most hinting maintains the
>> width of horiziontal amd vertical lines/strokes, slanting curved
>> lines tend to become out of proportion, or ugly. It is not easy.
>> To look nice in Chinese charcters have other rules, such certain
>> strokes extend to fill an empty space so there are no large gaps
>> inside the character, or contract to avoid touching.
> The most probable reason is that you have tried with the default
> hinting rules.
> Actually,each glyph should better be defined with at least two
> distinct paths, one for the smallest size, one for the largest size
> (sizes relative to the the Chinese square box), and a linear
> transformation will move the control points between these two
> extremes, relatively to the percentage of the square box the traits
> will use in its relative bounding box.
> This requires a specific transform, which comes before the final
> hinting (where the control points which are first relativey placed
> within a virtual square box is effectively scaled to the final
> rendering box), that final hinting will just adjust pixel positions
> relatively to horizontal and vertical constraints.
> Such morphing transform (in the virtual square space) would really
> improve the rendering at any final rendering point size and
> independantly of the resolution of the target device.
> The same morphing technic could be used to help improving the
> transformation of alphabetic fonts to other styles (like variable
> boldening, variable slanting for italic style, or special effects
> like shadowing or hollowing), and would give better results for
> fonts that are not provided in multiple styles or blacknesses.
> More generally, each control point is described with a natural
> position, but also with a path function (at least one vector for a
> linear transform), where the point will move according to a relative
> normalized index between 0.0 and 1.0 (for minimum relative size and
> maximum relative size).
> The simplest transform (linear) just requires two paths per glyph,
> which may be simpler to define.
> With such models, instead of defining zillions of glyphs, one for
> each ideograph, we just specify the glyphs for traits, and almost
> all ideographs are composed much more simply. Then some specific
> (complex) compositions may have their own specially tuned glyphs not
> reusing the traits definition. But at least, building a font
> covering very large subsets of ideographs would become much simpler.
> The set of default compositions could be standardized as well (but
> such standard would not prohibit compliant fonts to define specific
> glyphs for some ideographs where the composition is not easy to
> adapt without complexing it too much with too many alternate paths
> for traits).
> It would also help browsers, as they would have a database of
> possible compositions for missing composed characters not defined in
> the available fonts.
This message sent through Virus Free Email
This archive was generated by hypermail 2.1.5 : Tue Feb 06 2007 - 19:19:17 CST