Taco Hoekwater wrote:
Hi,
Li Yanrui (李延瑞) wrote:
Hi,
1. The characters overlaps each other and can not be set size.
The is a mini example.
\definefont[song][name:simsun at 12pt] \starttext
\song 测试
\stoptext
The attachment is its output.
Verified.
This actually looked fine here with the current 2010.05.21 11:10, but the beta 2010.05.22 12:06 MKIV is broken, producing the same output you have.
Some debugging applied. This line in font-otf.lua: tfm.format = (metadata.order2 == 1 and 'truetype') or 'opentype' produces 'opentype' for simsun.ttf, and so all glyphs are printed at 2.048 times the normal size in the PDF output. This is because the key metadata.order2 doesn't exist _anywhere_ in the context source (except in this test). But neither did it exist in the official current. The context current did tfm.format later. Patch to revert back to the current's behaviour: --- font-otf.lua~ 2010-05-23 10:20:10.979586135 +0200 +++ font-otf.lua 2010-05-23 10:31:14.153587544 +0200 @@ -1653,6 +1652,13 @@ local otfdata = tfmtable.shared.otfdata tfmtable.name = specification.name tfmtable.sub = specification.sub + if otfdata.metadata.order2 == 0 then + tfmtable.format = 'opentype' + elseif otfdata.metadata.order2 == 1 then + tfmtable.format = 'truetype' + else + tfmtable.format = specification.format + end local s = specification.size local m = otfdata.metadata.math if m then
2. the cid fonts cause MkIV gives a waring as following:
LuaTeX warning: lua-loaded font [44] (/usr/share/fonts/adobe/AdobeSongStd-Light) has no characters!
Verified, same here, even with the official current.
Something is broken in the handling of the 'subfonts' key, but I haven't figured out what (yet?). Best wishes, Taco