Re: Implementation of ideographic description characters

From: Philippe Verdy <>
Date: Thu, 6 Apr 2017 13:50:22 +0200

What is demonstrated here is how to build a CID-keyed font supporting the
the "unencoded glyphs" using IDS pseudo-encoding + OpenType "ccmp" (or
alternatively "liga") feature. It speaks about an Adobe registry ("ROS")
for some supported lexical dictionnaries, where encoded codepoints or
unencoded glyphs (CID-key) can be mapped to subsets implementable in
conforming fonts.

It does not demonstrate how you can convert multiple glyphs and alter their
metrics and placement to create composite glyphs. The actual composite
glyphs are still manually tuned to build fonts. There are some attempts to
generate composite glyphs automatically, but this has still always failed
with traditional (serif-style) fonts. There's some limited success with
simplified glyphs (not using strokes with variable weight), but the
generated glyphs are ugly because of their uneven stroke width (the
smallest parts are difficult to read, the larger ones are too bold and
should have their metrics reduced).

The assumption that width and height metrics are equal for all parts of a
single IDS composite gives wrong results. You need first to determine how
many subcolumns and ahow many subrows will tile the general composition
square then assign seaprate "weights" to subcolumns and subrows by counting
the number of stokes that interact on that dimension in the same
subcolumn/subrow. With these weights you can then properly distribute the
effective width of subcolumns, and effective height of subrows. With the
total "weights" computed separate for each dimension, you then need to take
its maximum value and make sure that stroke widths will not exceed this

Then you can place the glyphs in subcolumns/subrows, but you also need to
be able to determine parts of strokes that are allowed to exceed their
subcolumn/subrow limit : generally this is the thinest ending nodes of the
stroke, which may "touch" (intersect) some other strokes provided the
colliding strokes are not parallel or nearly paralell so that their area of
intersection will remain in a radius significantly smaller than the average
stroke width).

Such algorithm is not implementable directly in fonts, but it should be
possible to instruct some complex metrics in base glyphs to allow some
nodes to move slightly outside their definition box in a prefered
direction. When glyphs are heavily narrowed horizontally or flattened
vertically in their final rendering box (their size ratio is no longer a
square) you need more specific hinting. The situation becomes more complex
with some base glyphs for enclosure IDS (not just stacked side-by-side or
on top of each other), but things may become simpler if these base strokes
are themselves decomposed in IDS strings (using only side-by-side or
top-to-bottom + more basic strokes: the defined IDS dictionnary ignore
these subdecompositions because the standard IDS only use the encoded base
strokes and the subdecomposition of encoded base strokes would need special
codes for unencoded simple strokes.

But there's still no standard hinting in OpenType fonts to instruct CJK
glyphs so that their geometries may be properly adjusted while presxerving
the visual font weight and overall readability. So this requires specific
glyph renderers, and these glyph renderers are still not used by generic
text renderers. These algorithms are then used only as tools for generating
collections of glyphs in fonts in construction. Then complex glyphs are
manually tuned and various metrics are adjusted. Hinting instructions are
no logner present in the final (OpenType or SVG) fonts.

2017-04-06 9:28 GMT+02:00 gfb hjjhjh <>:

> Seems like Source Han Serif have just implemented such functionality? Or
> is this just partial.
> status/849178587680735232
Received on Thu Apr 06 2017 - 06:51:05 CDT

This archive was generated by hypermail 2.2.0 : Thu Apr 06 2017 - 06:51:05 CDT