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. http://blogs.adobe.com/CCJKType/2012/05/sp-ai0-ros.htmlIt 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 value. 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 <[email protected]>: > Seems like Source Han Serif have just implemented such functionality? Or > is this just partial. https://twitter.com/tualatrix/ > status/849178587680735232 >
