Dear Taco Hoekwater, In these days, I am trying to find a good way to use CJK characters with LuaTeX. At first, it looks somewhat trivial, but this topic is not trivial because of different typographical features of CJK countries. My first goal is to repeat the same thing what I had done with Omega. While I'm testing, I found that LuaTeX does not support the level 1 OFMs. Actually it is not hard to support the format in the point of DVI drivers' view. But it might not in the point of TeX's view. Anyway, I made a patch to support this format except for char_param (see \S95 entry of the ofm2opl manual, p.235) because I did not know how these parameters were used in LuaTeX. I tested a few sample OFM files of level 1. Especially I have cyberb.ofm (level 1) generated by ttf2tfm from Bitstream cyberbit.ttf. And, it was successful to get CJK characters in the DVI mode. It looks that LuaTeX does not support yet 16-bit characters in PDF mode. For CJK people, the first thing what we want is to support CJK characters in PDF mode without using subfont scheme (as CJK-LaTeX and Korean ko.TeX). The next thing is to support CJK typography. It may take quite long time to do it. I am preparing a topic for the first thing and I'd like to give a talk at this TUG conference for this topic. Because I am novice in LuaTeX, I hope the developers (I already met Hans and Hartmut) give me some helpful comment. Best regards, ChoF.
Hello ChoF, Jin-Hwan Cho wrote:
Dear Taco Hoekwater,
In these days, I am trying to find a good way to use CJK characters with LuaTeX.
At first, it looks somewhat trivial, but this topic is not trivial because of different typographical features of CJK countries.
My first goal is to repeat the same thing what I had done with Omega. While I'm testing, I found that LuaTeX does not support the level 1 OFMs. Actually it is not hard to support the format in the point of DVI drivers' view. But it might not in the point of TeX's view.
In truth I was not supporting OFM level 1 because the tools to create them are broken (at least all the ones I could find) and the technology is a dead end, it is much nicer to use TTF/OTF directly.
Anyway, I made a patch to support this format except for char_param (see \S95 entry of the ofm2opl manual, p.235) because I did not know how these parameters were used in LuaTeX.
I can apply your patch in any case.
I tested a few sample OFM files of level 1. Especially I have cyberb.ofm (level 1) generated by ttf2tfm from Bitstream cyberbit.ttf. And, it was successful to get CJK characters in the DVI mode. It looks that LuaTeX does not support yet 16-bit characters in PDF mode.
Not ones loaded from OFM files, no. I didn't know how to do it, and because of the 'dead technology' did not want to invest too much time in learning, either. I assume there is some mapping of tfmindex-to-ttfindex involved? But:
For CJK people, the first thing what we want is to support CJK characters in PDF mode without using subfont scheme (as CJK-LaTeX and Korean ko.TeX).
it works if you load the TTF/OTF font directly using lua. Hans does that in context mkiv. See this file http://www.pragma-ade.com/general/manuals/mk.pdf for an example of the output. That is straight from luatex, no dvipdfmx inbetween.
The next thing is to support CJK typography. It may take quite long time to do it.
I am preparing a topic for the first thing and I'd like to give a talk at this TUG conference for this topic. Because I am novice in LuaTeX, I hope the developers (I already met Hans and Hartmut) give me some helpful comment.
Best wishes, Taco
Dear Taco, Thank you very much for your quick reply. On May 23, 2008, at 9:58 PM, Taco Hoekwater wrote:
In truth I was not supporting OFM level 1 because the tools to create them are broken (at least all the ones I could find) and the technology is a dead end, it is much nicer to use TTF/OTF directly.
You are right except for ttf2tfm (patched by me for a few years ago). OFM level 1 is better than OFM level 0 because the file size is too big in the case of level 0 for CJK fonts. Anyway, I agree with your idea that it might be better to use TTF/OTF directly. Actually I always insisted on this idea.
Anyway, I made a patch to support this format except for char_param (see \S95 entry of the ofm2opl manual, p.235) because I did not know how these parameters were used in LuaTeX.
I can apply your patch in any case.
I do not mind if you do not apply.
I tested a few sample OFM files of level 1. Especially I have cyberb.ofm (level 1) generated by ttf2tfm from Bitstream cyberbit.ttf. And, it was successful to get CJK characters in the DVI mode. It looks that LuaTeX does not support yet 16-bit characters in PDF mode.
Not ones loaded from OFM files, no. I didn't know how to do it, and because of the 'dead technology' did not want to invest too much time in learning, either. I assume there is some mapping of tfmindex-to-ttfindex involved?
Yes. It's really hard to find anyone using OFM files. I agree that this is 'dead technology'. Then, what do you mean by the mapping of tfmindex-to-ttfindex?
But:
For CJK people, the first thing what we want is to support CJK characters in PDF mode without using subfont scheme (as CJK-LaTeX and Korean ko.TeX).
it works if you load the TTF/OTF font directly using lua. Hans does that in context mkiv. See this file
http://www.pragma-ade.com/general/manuals/mk.pdf
for an example of the output. That is straight from luatex, no dvipdfmx inbetween.
Looks quite interesting. Does it use fontforge library? I tested a little with the fontforge library in LuaTeX. But it was not successful for CJK fonts. It took too much time. Anyway, thanks for the information. I have something to study in this weekend. Maybe my family do not like you because you took my time from my family. Best regards, ChoF.
Hi, Jin-Hwan Cho wrote:
Looks quite interesting. Does it use fontforge library? I tested a little with the fontforge library in LuaTeX. But it was not successful for CJK fonts. It took too much time.
Yes, it uses fontforge. I attach a small plain.tex test file and hacked version of Wlodek's opentype.lua. This is just a rough demonstration, proper support needs (much?) more work done of course. I just wanted to show that the glyphs are really there and can be accessed. Best wishes, Taco callback.register('define_font', function(name, size) fonttype = nil filename = kpse.find_file(name,"opentype fonts") if (filename) then fonttype = 'opentype' else filename = kpse.find_file(name, "truetype fonts") end if filename and not fonttype then fonttype = 'truetype' end if fonttype then if (size < 0) then size = (- 655.36) * size end ff, messages = fontforge.open(filename) if messages and #messages > 0 then for _, m in ipairs(messages) do texio.write_nl("load otf: [" .. filename .. "] warning: " .. m) end end ttffont = fontforge.to_table(ff) 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 / ttffont.units_per_em names_of_char = { } if ttffont.map then 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 elseif ttffont.subfonts then for _, subfont in pairs(ttffont.subfonts) do for char, glyph in pairs(subfont.glyphs) do if glyph.width then local unic = glyph.unicode if unic and unic >= 0 then f.characters[unic] = { index = char, width = glyph.width * mag, } end end end end f.encodingbytes = 2 end f.filename = filename f.type = 'real' f.format = fonttype f.embedding = "subset" f.cidinfo = { registry = "Adobe", ordering = "Identity", supplement = 0, version = 1 } end else f = font.read_tfm(name, size) end return f end )
On May 23, 2008, at 11:14 PM, Taco Hoekwater wrote:
Jin-Hwan Cho wrote:
Looks quite interesting. Does it use fontforge library? I tested a little with the fontforge library in LuaTeX. But it was not successful for CJK fonts. It took too much time.
Yes, it uses fontforge. I attach a small plain.tex test file and hacked version of Wlodek's opentype.lua. This is just a rough demonstration, proper support needs (much?) more work done of course. I just wanted to show that the glyphs are really there and can be accessed.
Thank you very much.
\pdfoutput=1
\directlua0{ dofile('opentype.lua') }
Where can I find "opentype.lua"? Best regards, ChoF.
Jin-Hwan Cho wrote:
On May 23, 2008, at 11:14 PM, Taco Hoekwater wrote:
Jin-Hwan Cho wrote:
Looks quite interesting. Does it use fontforge library? I tested a little with the fontforge library in LuaTeX. But it was not successful for CJK fonts. It took too much time.
Yes, it uses fontforge. I attach a small plain.tex test file and hacked version of Wlodek's opentype.lua. This is just a rough demonstration, proper support needs (much?) more work done of course. I just wanted to show that the glyphs are really there and can be accessed.
Thank you very much.
\pdfoutput=1
\directlua0{ dofile('opentype.lua') }
Where can I find "opentype.lua"?
Same email message, second attachment. Best wishes, Taco
On May 23, 2008, at 11:36 PM, Taco Hoekwater wrote:
Jin-Hwan Cho wrote:
On May 23, 2008, at 11:14 PM, Taco Hoekwater wrote:
Jin-Hwan Cho wrote:
Looks quite interesting. Does it use fontforge library? I tested a little with the fontforge library in LuaTeX. But it was not successful for CJK fonts. It took too much time.
Yes, it uses fontforge. I attach a small plain.tex test file and hacked version of Wlodek's opentype.lua. This is just a rough demonstration, proper support needs (much?) more work done of course. I just wanted to show that the glyphs are really there and can be accessed. Thank you very much. \pdfoutput=1
\directlua0{ dofile('opentype.lua') } Where can I find "opentype.lua"?
Same email message, second attachment.
I found. Actually I wonder that what "\byecallback" is. Thanks again. Best regards, ChoF.
Le 23 mai 08 à 14:58, Taco Hoekwater a écrit :
them are broken (at least all the ones I could find) and the technology is a dead end, it is much nicer to use TTF/OTF directly.
except for the fact that OFM provides you with TeX-related information such as italic correction, smart ligatures, etc. which you don't have in TTF/OTF -- + -----------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis.haralambous@telecom- bretagne.eu | | Directeur d'Études http://omega.enstb.org/ yannis | | Tel. +33 (0)2.29.00.14.27 | | Fax +33 (0)2.29.00.12.82 | | Département Informatique | | TELECOM Bretagne | | Technopôle de Brest Iroise, CS 83818, 29238 Brest CEDEX 3, France | | Coordonnées Google-Earth : 48°21'31.57"N 4°34'16.76"W | + -----------------------------------------------------------------------+ ...pour distinguer l'extérieur d'un aquarium, mieux vaut n'être pas poisson ...the ball I threw while playing in the park has not yet reached the ground Es gab eine Zeit, wo ich nur ungern über Schubert sprechen, nur Nächtens den Bäumen und Sternen von ihm vorerzählen mögen.
Yannis Haralambous wrote:
Le 23 mai 08 à 14:58, Taco Hoekwater a écrit :
them are broken (at least all the ones I could find) and the technology is a dead end, it is much nicer to use TTF/OTF directly.
except for the fact that OFM provides you with TeX-related information such as italic correction,
That is true for an OFM font that is created by hand, but does ttf2tfm add this information automatically?
smart ligatures,
This is tongue in cheek? I'd say features are much more powerful than tex's ligature mechanism ... Best wishes, Taco
On May 23, 2008, at 10:50 PM, Taco Hoekwater wrote:
Yannis Haralambous wrote:
Le 23 mai 08 à 14:58, Taco Hoekwater a écrit :
them are broken (at least all the ones I could find) and the technology is a dead end, it is much nicer to use TTF/OTF directly. except for the fact that OFM provides you with TeX-related information such as italic correction,
That is true for an OFM font that is created by hand, but does ttf2tfm add this information automatically?
No, ttf2tfm just extracts character width information because italic correction and ligature are not used in CJK typesetting. Best, ChoF.
Yannis Haralambous wrote:
Le 23 mai 08 à 14:58, Taco Hoekwater a écrit :
them are broken (at least all the ones I could find) and the technology is a dead end, it is much nicer to use TTF/OTF directly.
except for the fact that OFM provides you with TeX-related information such as italic correction, smart ligatures, etc. which you don't have in TTF/OTF
fyi, there are plans to add this information to the lm and gyre otf fonts (extra tables) 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 (4)
-
Hans Hagen -
Jin-Hwan Cho -
Taco Hoekwater -
Yannis Haralambous