Re: MKIV Chinese typesetting

["Wolfgang Schuster" <schuster.wolfgang@googlemail.com>]

On Jan 28, 2008 3:17 AM, Arthur Reutenauer
<arthur.reutenauer@normalesup.org> wrote:
>         Hello,
>
>   Thanks for this comprehensive review.  If I'm not mistaken, there is
> no specific code for CJKV typesetting in Mark IV; the examples in mk.pdf
> seem to use the generic font loading mechanism.

This is wrong, fon-otf contains a few lua macros about linebreaking
and char-def has information about the character width (full width,
half width ...)
and other information like opening punctuation, parenthesis but none
of them is finished.

>   I would like to answer more completely, but don't have much time for
> the moment.  About some of your remarks:
>
> > so I think a new feature should be added to map all the Chinese puncts
> > into english while at the same time, a space should be added after the
> > English punct marks.
>
>   Would it not be better to automatically add shrinkable glue after
> Chinese punctuation, rather than replacing the character by force?  This
> would be very much in line with the general TeX philosophy of setting
> text (and would probably suppress the need for half-width forms in the
> font altogether).
>
> > - pp118, penultimate example, box 2, line1, the ' punct mark should
> > not appear at the end of the line
>
>   This should be taken care of by adding an appropriate penalty before
> the character.
>
> > - pp118, ultimate example, box 2, line2, in fact, if you want do
> > perfect Chinese typesetting, all the puncts which begin a line or end
> > a line should be closed to the margin line
>
>   Do you mean simply closer to the margin, or in the margin itself
> (protruding)? Protruding is already possible in pdfTeX; I believe it is
> available in LuaTeX as well, although it might be broken for the moment
> (Taco?).  Setting the character closer to the margin should be possible
> as well, as a modified form of protruding, I trust.
>
> > A small skip should be left between Chinese and English which makes
> > the result much better. usually the space is a quarter of a chinese
> > character width. A TeX expression should like:
> > \hspace{0.25em plus 0.125em minus 0.08em}
>
>   Again, this can be taken care of by automatically adding this glue
> between pairs of character of the appropriate category.
>
> > The last important thing for English and Chinese bi-lingual
> > typesetting is that: do not use English glyphs in Chinese fonts
>
>   Sure, there should be a possibility of specifying a Western font to be
> used inside Chinese text.

Could be done with cirtual fonts but we need a interface.

> > - the following script produce an error: Invalid field id penalty for
> > node type glyph (1).
>
>   I don't have that error here.  This is very big font; are you sure it
> has been read entirely and correctly written to the cache?  Lua crashed
> on my machine when I first compiled your example, and only a partial
> font hash was written to the cache (ConTeXt didn't crash, so the first
> compilation apparently ended well, but the cache was already filled with
> a partial font).  I can imagine that problems will arise in the presence
> of a partially hashed font in the cache.
>
>   Anyway, the code looks quite weird to me:
>
> > \definefontfeature[chinese][mode=node,script=hang,lang=zht,script=hani,lang=dlft]
>
>   This means that you activate two different scripts at the same time
> (hang == Hangul and hani == Han ideographs), and also two languages at
> the same time (zht == Chinese Traditional and dlft is probably a typo
> for dflt == default).  I can't imagine what that is supposed to mean,
> and activating Traditional Chinese is probably wrong with Adobe Song Std
> which is a Simplified Chinese font.  A saner definition of that feature
> would be in my opinion:
>
>         \definefontfeature[chinese-traditional][mode=node,script=hani,lang=zhs]

You need the hang script, it takes care about the linebreak.

>   I know this code comes from mk.pdf, but I think it is a mistake.
>
>   Finally, there is an interesting article by Jin-Hwan Cho (the dvipdfmx
> author) and Haruhiko Okumura about CJKV typesetting with Omega a couple
> of years ago.  They have implemented all of the rules you mention above
> and a bit more; and although they used OTPs at the time, it should be
> quite straighforward to transpose it in Lua code (actually, I've done it
> a couple of months ago, but I have used plain LuaTeX, and in ConTeXt it
> should probably done using node processors or something).
>
>         http://project.ktug.or.kr/omega-cjk/tug2004-preprint.pdf

This this currently done in font-otf.lua.

Greetings,

Wolfgang
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________