Hi, I was just playing luatex with the script in http://luatex.bluwiki.com/go/Use_a_TrueType_font , and found some problem. On Windows XP English Edition or Debian GNU/Linux with luatex 0.10.1 I wrote the following script: ------------------------------------------------------------------file begins \pdfoutput1 \directlua0{ callback.register('define_font', function(name, size) filename=kpse.find_file(name,"truetype fonts") if (filename) then if (size < 0) then size = (- 655.36) * size end ttffont = fontforge.to_table(fontforge.open(filename)) if ttffont then f = { } f.name = ttffont.fontname f.fullname = ttffont.names[1].names.fullname f.parameters = { } f.designsize = size f.size = size direction = 0 f.parameters.slant = 0 f.parameters.space = size * 0.25 f.parameters.space_stretch = 0.3 * size f.parameters.space_shrink = 0.1 * size f.parameters.x_height = 0.4 * size f.parameters.quad = 1.0 * size f.parameters.extra_space = 0 f.characters = { } mag = size / 2048 names_of_char = { } for char, glyph in pairs(ttffont.map.map) do names_of_char[ttffont.glyphs[glyph].name] = ttffont.map.backmap[glyph] end names_of_glyph = { } for char, glyph in pairs(ttffont.map.map) do names_of_glyph[ttffont.glyphs[glyph].name] = glyph end for char, glyph in pairs(ttffont.map.map) do glyph_table = ttffont.glyphs[glyph] f.characters[char] = { index = glyph, width = glyph_table.width * mag, name = glyph_table.name, } if glyph_table.kerns then local kerns = { } for _, kern in pairs(glyph_table.kerns) do kerns[names_of_char[kern.char]] = kern.off * mag end f.characters[char].kerns = kerns end end f.filename = filename f.type = 'real' f.format = 'truetype' f.cidinfo = { registry = "Adobe", ordering = "Identity", supplement = 0, version = 1 } end else f = font.read_tfm(name, size) end return f end ) } %\font\times= times.ttf at 10pt \times Like oratory, music, dance, calligraphy -- like anything that lends its grace to language -- typography is an art that can be deliberately misused. It is a craft by which the meanings of a text (or its absence of meaning) can be clarified, honored and shared, or knowingly disguised. %\font\arial= arial.ttf at 10pt \arial In a world rife with unsolicited messages, typography must often draw attention to itself before it will be read. Yet in order to be read, it must relinquish the attention it has drawn. Typography with anything to say therefore aspires to a kind of statuesque transparency. Its other traditional role is durability: not immunity to change, but a clear superiority to fashion. Typography at its best is a visual form of language linking timelessness and time. %\font\simhei= simhei.ttf at 10pt \simhei %中文 \bye ------------------------------------------------------------------End of file Step 1 times.ttf for Times New Roman and arial.ttf for Arial is available in Microsoft Windows XP, and they looks pretty well. so this script works. Step 2 but then I load a Chinese font, simhei.ttf. It is also available in the English Edition of Windows XP. and now luatex reports: Warning: Glyph 257 is named middot which should mean it is mapped to Unicode U+00B7, but Glyph 194 already has that encoding. and then it crash: This went wrong:[string "luas[0]"]:1: attempt to perform arithemetic on field 'width' (a nil value). <to be read again> \simhei So it fails to compile. Step 3 Then I found a smaller Chinese font named simkai.ttf, you can find it in the Simplified Chinese version of Windows XP. it compiles successfully with the Warning message but without the error message. it generate the pdf file, but the two chinese characters are so close (see the a.pdf I enclosed here) that they are almost in the same place. if I change mag = size / 2048 to mag = size / 256 then the space looks right. Step 4 I tried more Chinese ttf fonts and found that only a few can pass the test, and among those few, the character box width seems all wrong. So how can I make things right? or it is just a bug in luatex? Yue Wang
Hi, Sherry Zhang wrote:
Step 2 but then I load a Chinese font, simhei.ttf. It is also available in the English Edition of Windows XP. and now luatex reports: Warning: Glyph 257 is named middot which should mean it is mapped to Unicode U+00B7, but Glyph 194 already has that encoding.
and then it crash: This went wrong:[string "luas[0]"]:1: attempt to perform arithemetic on field 'width' (a nil value). <to be read again> \simhei
So it fails to compile.
This was a bug in 0.10.1 that should be fixed in 0.10.2. It is not actually related to the warning, Luatex just never outputted glyph width information for fonts that contain vertical metrics.
Step 3 Then I found a smaller Chinese font named simkai.ttf, you can find it in the Simplified Chinese version of Windows XP. it compiles successfully with the Warning message but without the error message. it generate the pdf file, but the two chinese characters are so close (see the a.pdf I enclosed here) that they are almost in the same place. if I change mag = size / 2048
Here, it should use f.units_per_em instead of 2048, as not all truetype fonts use the same value. I am not sure if that is the problem, but it seems likely.
Step 4 I tried more Chinese ttf fonts and found that only a few can pass the test, and among those few, the character box width seems all wrong. So how can I make things right? or it is just a bug in luatex?
Probably te same bug as from Step 2, so I advise to try again with the latest version. Best wishes, Taco
Hi, Taco:
On 8/14/07, Taco Hoekwater
This was a bug in 0.10.1 that should be fixed in 0.10.2. It is not actually related to the warning, Luatex just never outputted glyph width information for fonts that contain vertical metrics.
Ahh, yes, after a couple minutes' compile, I finally come up with luatex 0.10.2, and it works fine with these fonts!Thank you!
Here, it should use f.units_per_em instead of 2048, as not all truetype fonts use the same value. I am not sure if that is the problem, but it seems likely. I should say sorry for not reading the 100 pages or so manual and just follow the unofficial wiki link. It works fine now. Thank you.
Probably te same bug as from Step 2, so I advise to try again with the latest version. The problem is solved.
Best wishes, Taco
BTW, I am very interested in LuaTeX and I will do more testing work on typesetting Traditional or Simplified Chinese in the future. Regards Sherry Zhang
Hi Taco, Now here comes the new problem. at this time I test two opentype fonts: MinionPro-Regular.otf AdobeSongStd-Light.otf They are free (for charge) fonts and are available in the Acrobat Reader 8.0 package. so I change the filename=kpse.find_file(name,"truetype fonts") to filename=kpse.find_file(name,"opentype fonts") mag = size / 2048 to mag=size/ttffont.units_per_em and f.format = 'truetype' to f.format='opentype' Now I test MinionPro-Regular.otf, it works fine, so this method works. but I then test the AdobeSongStd-Light.otf, it reports: The 'size' feature of this font conforms too Adobe's early misinterpretation of the otf standard. Bad call to gww_iconv_open, neither arg is UCS4 Bad call to gww_iconv_open, neither arg is UCS4 Bad call to gww_iconv_open, neither arg is UCS4 Bad call to gww_iconv_open, neither arg is UCS4 Bad call to gww_iconv_open, neither arg is UCS4 Segmentation fault (core dumped) so LuaTeX exit abnormally. btw, when loading the opentype or truetype fonts like the way I do, some TeX commands like ---, ``, '', ff, ft, fft,ff,fi does not work. Is there someting wrong? Sherry Zhang
Sherry Zhang wrote:
Now I test MinionPro-Regular.otf, it works fine, so this method works. but I then test the AdobeSongStd-Light.otf, it reports:
The 'size' feature of this font conforms too Adobe's early misinterpretation of the otf standard. Bad call to gww_iconv_open, neither arg is UCS4 Bad call to gww_iconv_open, neither arg is UCS4 Bad call to gww_iconv_open, neither arg is UCS4 Bad call to gww_iconv_open, neither arg is UCS4 Bad call to gww_iconv_open, neither arg is UCS4 Segmentation fault (core dumped)
so LuaTeX exit abnormally.
these are cid fonts ... this is curretly being worked on so later this week ...
btw, when loading the opentype or truetype fonts like the way I do, some TeX commands like ---, ``, '', ff, ft, fft,ff,fi does not work. Is there someting wrong?
luatex only provides a loader; ligatures can be handled by tex, in which case you need to add the ligature info to the tfmtable; an other option is to manipulate the node lists; for the tfm tabel think of ... characters[slot('f')].ligatures = { [slot('i')] = { char = slot('fi'), type = 0 }, [slot('l')] = { char = slot('fl'), type = 0 } } characters[slot('ff')].ligatures = { [slot('i')] = { char = slot('ffi'), type = 0 }, [slot('l')] = { char = slot('ffl'), type = 0 } } etc ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Sherry Zhang wrote:
width = glyph_table.width * mag,
width = (glyph_table.width or 0) * mag,
but then I load a Chinese font, simhei.ttf. It is also available in the English Edition of Windows XP. and now luatex reports: Warning: Glyph 257 is named middot which should mean it is mapped to Unicode U+00B7, but Glyph 194 already has that encoding.
i dunno about this one, but fonts can have bugs and any of the fonts that i use report inconsistencies
and then it crash: This went wrong:[string "luas[0]"]:1: attempt to perform arithemetic on field 'width' (a nil value). <to be read again> \simhei
So it fails to compile.
see above, you can catch this, it;s not a luatex issue but a lua issue
mag = size / 2048 to mag = size / 256 then the space looks right.
choosing the right spacing is an art -) keep in mind that many tfm files hav evalues chosen at some point, and not always related to the font info; with open type choices need to be made based on info in the font
Step 4 I tried more Chinese ttf fonts and found that only a few can pass the test, and among those few, the character box width seems all wrong. So how can I make things right? or it is just a bug in luatex?
a bug and it's being worked on Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Hans Hagen
-
Sherry Zhang
-
Taco Hoekwater