[NTG-context] readposition() in mkiv font-dsp.lua

2019-05-17 Thread Dohyun Kim
Hi,

I am using luaotfload.sty in TexLive 2019, that is latex.
On my mac, everything is flawlessly working.

But I've heard from somebody that NotoSansCJKkr-Regular etc fonts
are not usable on Windows machine; so I tested on 32-bit Windows 10
virtual machine with small memory (2GB) and it was really unusable.

I did some digging into the source code of luaotfload package.
Now I have a guess that readposition() in font-dsp.lua might be the culprit.
For instance, when format == 0x04 and the result of readshort(f) == 0,
then the return value of the function is currently "true".
After it has been changed to "false", NotoSansCJKkr fonts are working
quite well on 32-bit Windows.

With the same changes of readposition() on my 64-bit Mac,
the elapsed time for making cache file of NotoSansCJK fonts has been
dramatically reduced: from 25 seconds to 10 seconds. And the resulting
cache file is perfectly the same as before.

So I would like to suggest those return values to be changed to "false".
Certainly, I do not know much about opentype spec, so I might be wrong and
there could be good reasons for current code state.

Regards,
-- 
Dohyun Kim
Seoul, Republic of Korea
___
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://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___


[NTG-context] [luatex-plain] disappearing math-on node

2014-04-03 Thread Dohyun Kim
Hi,

This is a bug report based on the issue discussed at
https://github.com/lualatex/luaotfload/issues/212

\font\tenrm{file:lmroman10-regular.otf:mode=node;script=latn}\tenrm
\setbox0\vbox{%
  x\penalty-1
  $a$x$a$
}
\unvbox0
\setbox0\lastbox
\unhbox0
\end

The plain tex code shown above fails with a lua error:
luatex-fonts-merged.lua:9616: attempt to index local 'current' (a nil value)

My guess is: as math-on (math-off too) is a discardable item after a
linebreak, the first math-on node has gone away. So the
math-on/math-off pair has become broken, by which the behavior of
node.end_of_math is confused.

Regards,
-- 
Dohyun Kim
Seoul, Republic of Korea
___
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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


[NTG-context] font option slant does not work occasionally

2013-05-19 Thread Dohyun Kim
Hi,

With the following example, I cannot get slanted shape of unbatang.

\setscript[hangul]
\setupbodyfont[unfonts]
\starttext
가나다 {\it 가나다} 가나다
\stoptext

Regards,
--
Dohyun Kim
Seoul, Republic of Korea
___
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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] missing chars in cid-keyed font table

2013-05-08 Thread Dohyun Kim
Hi,

With AdobeMyungjoStd-Medium.otf, I cannot typeset some chinese
characters. Here is a simple tex source:

\starttext
\definedfont[name:adobemyungjostdmedium]
黃金빛
\stoptext

U+9EC3 黃 and U+91D1 金 are missing in the pdf.
Incidentally, during font cache I get a bunch of warning messages as follows:

otf loading  weird, unicode U+09EC3 points to U+02FC8 with index 0x01EF7

Regards,
--
Dohyun Kim
Seoul, Republic of Korea
___
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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] luatex-plain metapost

2009-10-26 Thread Dohyun Kim
2009/10/26 luigi scarso luigi.sca...@gmail.com:
 luigi scarso wrote:
 OK -- I understand this.
 Any plan to implement btex...etex in mplib ?

 Not btex ... etex, no.

 Maybe something new will appear in the long run, maybe not.

 Best wishes,
 Taco

well, you can set up some kind of mechanism
that eventually produces a picture that mp can handle, or roll out your own 
code
anyhow, i see not much reason for spending
time on that kind of support for plain as i have no use for it

Hans


 OK.

Well... I have implemented btex .. etex feature
upon Hans  Taco's luatex-mplib.* files
mostly by mimicking the implementation in context.

Please visit
http://cvs.ktug.or.kr/viewcvs/ko.TeX/luatexko/luatexplainko-mplib.tex
http://cvs.ktug.or.kr/viewcvs/ko.TeX/luatexko/luatexplainko-mplib.lua

Best,
-- 
Dohyun Kim
___
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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] MkIV italic correction?

2009-05-26 Thread Dohyun Kim
2009/5/22 Taco Hoekwater t...@elvenkind.com:


 Hans Hagen wrote:
 Taco Hoekwater wrote:

 Khaled Hosny wrote:
 Not very helpful in this situation, but FontForge has a non-standard
 italic correction (ITLC) table[1], may be TeX related OpenTyp font
 projects like Latin Modern and Gyre fonts can use it?

 That would perhaps not be a bad idea. If that table is there then
 luatex will automatically use it (it is a subtable of 'TeX ', which
 also contains height and depth information, and font dimensions).

 so, that data would end up in a regular feature/lookup? of is it an
 entry in the glyph?

 They are automatically merged into the glyph, as

        glyph.italic_correction
        glyph.tex_height
        glyph.tex_depth


Hi,

Considering current state that we don't know any fonts that has ITLC table,
it would be better than nothing to implement italic correction as follows.
In the following code, fontdata is a table returned by the function
fonts.define.read.

local param = fontdata.parameters
local italicangle = fontdata.shared.otfdata.metadata.italicangle
if italicangle and italicangle  0 then
local uwidth = fontdata.shared.otfdata.metadata.uwidth or 40
local factor = fontdata.factor or 655.36
param.slant = - math.tan(italicangle*math.pi/180) * param.quad
for i,v in pairs(fontdata.characters) do
local gl = fontdata.descriptions[i]
local it = (gl.boundingbox[3] - gl.width + uwidth*0.5) * factor
if it  0 then v.italic = it end
end
end

Best,
Dohyun Kim
___
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
___


Re: [NTG-context] beta

2009-05-19 Thread Dohyun Kim
2009/5/20 Hans Hagen pra...@wxs.nl:
 Hi,

 I uploaded a beta. Not that many fixes (if someone can collect structure
 related bugs ...), only a few.


Let me raise several issues about luatex-plain.

First, newly released beta breaks luatex-plain,
because luat-sto.lua is not included in luatex-fonts.lua.
Without this, luatex-plain fails when trying to define
storage.shared.attributes_last_private.

Secondly, name: method of font searching does not work.
The reason is version mismatch between font-dum.lua and
luatex-fonts-names.lua.  The former requires data.version == 1.07,
while the latter's version is 1.08, if it is generated with current beta.

Thirdly, some fonts have extension TTF rather than ttf,
so that function resolvers.find_file fails while finding,
for example, gentium font (filename: GenR102.TTF).
Here is my patch:

- return kpse.find_file(name,(kind and kind ~=  and (remapper[kind]
or kind)) or tex)
+ return kpse.find_file(name,(kind and kind ~=  and
(remapper[string.lower(kind)] or kind)) or tex)

Lastly, current beta does not support subfonts contained in
TTC (truetype collection).  TTC fonts are becoming more and more
difficult to find, but we still can find them especially in CJK world.
It's quite simple to support them:
just commenting out three lines from font-dum.lua

-- function fonts.define.get_specification(str)
-- return , str, , :, str
-- end

Thank you for your great work, as always.
Dohyun Kim
___
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
___


Re: [NTG-context] Chinese opentype fonts can not be loaded in luatex-plain

2009-05-12 Thread Dohyun Kim
2009/5/12 Hans Hagen pra...@wxs.nl:
 Yanrui Li wrote:

 Hi Hans,

 I tried to use Chinese opentype fonts with luatex + plain fmt but I
 failed. Only with Chinese TTF fonts it can work.

 This a simple example:

 \pdfoutput=1
 \font\myfont=AdobeSongStd-Light

 \myfont
 我想实现 LuaTeX 对中文的支持

 \end

 When I compiled it, I got the following messages:

 This is LuaTeX, Version beta-0.41.0-2009051221 (Web2C 7.5.7)
  \write18 enabled.
 (tt.tex (luatex-basics.tex) (luatex-fonts.tex luatex-fonts-merged.lua
 luatex
 -fonts.lua loaded in 0.027 seconds) (luatex-mplib.tex)
 LuaTeX warning: lua-loaded font [51]
 (/usr/share/fonts/adobe/AdobeSongStd-Light
 .otf) has no characters!
 [1{/opt/context/tex/texmf/fonts/map/pdftex/plain/pdftex.map}]
 ){/opt/context/te

 x/texmf/fonts/enc/dvips/lm/lm-rep-cmrm.enc}/opt/context/tex/texmf/fonts/type1/
 public/lm/lmr10.pfb
 Output written on tt.pdf (1 page, 17128 bytes).
 Transcript written on tt.log.

 this is because a cidmap is needed and the kpse that you use does not have
 it; upcoming versions of kpse (and luatex's kpse lib) will support it given
 that you also adapted your texmf.cnf accordingly then

 so a bit patience is needed


Yes, that is a source of problem; more obstacles, however, are waiting for us.

1.
To test an cid-keyed opentype fonts, I have copied *.cidmap files
into current directory and processed a simple document with luatex-plain.
But it did not work:

This is LuaTeX, Version beta-0.40.1-2009050920 (Web2C 7.5.7)
 \write18 enabled.
(nanumotf.tex
(/media/disk/context/tex/texmf-context/tex/generic/context/luatex-basics.tex)
(/media/disk/context/tex/texmf-context/tex/generic/context/luatex-fonts.tex lu
atex-fonts-merged.lua luatex-fonts.lua loaded in 0.027 seconds)
(/media/disk/context/tex/texmf-context/tex/generic/context/luatex-mplib.tex)
LuaTeX warning: lua-loaded font [51] (/media/disk/context/tex/texmf-local/fonts
/opentype/korean/NanumGothic.otf) has no characters!

The same message as that of Li Yanrui's experiment, which would not
occur on windows machine. But I am on my linux box, whose
file system, as you know, distinguishs upper- and lower-case letters:
Adobe-Korea1-2.cidmap is quite different from adobe-korea1-2.cidmap.
So I added one line into luatex-fonts-merged.lua as follows:

--- ../tex/texmf-context/tex/generic/context/luatex-fonts-merged.lua
2009-05-12
18:29:55.0 +0900
+++ luatex-fonts-merged.lua 2009-05-13 01:14:55.0 +0900
@@ -3898,6 +3898,7 @@

 local function locate(registry,ordering,supplement)
 local filename = format(template,registry,ordering,supplement)
+filename = string.lower(filename)
 local cidmap = fonts.cid.map[filename]
 if not cidmap then
 if trace_loading then


2.
However, I still got an error even after that one-line patch:

This is LuaTeX, Version beta-0.40.1-2009050920 (Web2C 7.5.7)
 \write18 enabled.
(nanumotf.tex
(/media/disk/context/tex/texmf-context/tex/generic/context/luatex-basics.tex)
(/media/disk/context/tex/texmf-context/tex/generic/context/luatex-fonts.tex lu
atex-fonts-merged.lua luatex-fonts.lua loaded in 0.029 seconds)
(/media/disk/context/tex/texmf-context/tex/generic/context/luatex-mplib.tex)
! LuaTeX error ./luatex-fonts-merged.lua:3879: attempt to call field 'loaddata'
 (a nil value).

In other words, loaddata is not defined.  So I issued grep command,
which helped me finding io.loaddata function defined in l-io.lua.

In sum:
even after modification of kpse, two more problems should be fixed.
1. lowering uppercase filename before searching cidmap
2. including l-io.lua into luatex-plain

Regards,
Dohyun Kim
___
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
___


Re: [NTG-context] beta release

2009-03-02 Thread Dohyun Kim
2009년 3월 2일 (월) 오후 7:02, Hans Hagen pra...@wxs.nl님의 말:
 Dohyun Kim wrote:
 Or it would be better if the order is reversed, that is to say,
 if the line mentioned above and other adjacent lines comes before
 the hash table of individual characters.

 then we'd need to do each assignment individually; so instead i now have

 for i=0x0FF00,0x0FFEF do if not hash[i] then hash[i] = chinese
 end end

 i.e. a test before an assigment so that the first table takes precedence.


ok.
Then, why don't you do the same for other assignments to chinese?
because, for instance, non-starters too are currently overridden by chinese.

Dohyun Kim
___
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
___


Re: [NTG-context] new beta

2009-02-18 Thread Dohyun Kim
2009/2/18 Hans Hagen pra...@wxs.nl:
 Hi,

 There is a new beta: a few additions to math as well as a prelude to new cjk
 support, now to be triggered explicitly (since the methods differ too much
 we cannot share them)

 \setscript[hangul]

 \setscript[hanzi]% arthur, is this the right name?


I have tested Chinese translation of Universal Declaration of Human Rights
available at http://www.un.org/chinese/hr/issue/udhr.htm .

1.
\**thedefinedfont** 认
\glue 0.0 plus 20.0 %% line break should not occur
\**thedefinedfont** , % U+FF0C
\glue 0.0 plus 20.0
\**thedefinedfont** 乃

Line break is prohibited before U+FF0C (fullwidth comma)
but current beta inserts glue.  This should be corrected.
The same for U+FF1B (fullwidth semicolon).

2.
\**thedefinedfont** 由
\penalty 1
\glue 0.0 plus 20.0
\**thedefinedfont** 、 % U+3001
\penalty 1 %% this should be deleted
\glue 0.0 minus 5.0
\glue 0.0 plus 20.0
\**thedefinedfont** 正

Line break is allowed after U+3001 (ideographic comma),
so \penalty1 after U+3001 should not be inserted.
The same for U+3002 (ideographic full stop).

3.
I don't know much about Chinese typesetting, but IMO
it would be better if these full width CJK punctuations
is forced to half width and 0.5em glue is inserted after
those characters.

Dohyun Kim
___
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
___


Re: [NTG-context] new beta

2009-02-17 Thread Dohyun Kim
2009/2/18 Hans Hagen pra...@wxs.nl:
 Hi,

 There is a new beta: a few additions to math as well as a prelude to new cjk
 support, now to be triggered explicitly (since the methods differ too much
 we cannot share them)

 \setscript[hangul]


Now the Korean typesetting has become almost perfect.
Thanks a lot, Hans.  I really appreciate it.

We have three more things to do, however.

1.  inter_char_stretch_factor = 2.00 seems to be too large value.
I do not think that even Chinese or Japanese would allow that big value.
I suggest 0.50 instead.   Mr Wang, how do you think about that?

2.  Upon tracing output, I get :

..\*unbatang12ptrmtfrm* 居
..\penalty 1
..\*unbatang12ptrmtfrm* )
..\penalty 1 %% this should be deleted.
..\glue 0.0 plus 6.0
..\*unbatang12ptrmtfrm* 하

\panalty1 after closing parenthesis should be deleted,
so that line-breaking can occur at this point.

3.  Line-breaking rule for medieval Korean is a little imperfect.
When input string is 가나, all from Hangul Jamo area, I get :

..\*unbatang12ptrmtfrm* U+F017E % U+1100
..\*unbatang12ptrmtfrm* U+F0355 % U+1161
%% \penalty50 should be inserted here
..\*unbatang12ptrmtfrm* U+F0180 % U+1102
..\*unbatang12ptrmtfrm* U+F0355 % U+1161

As I said in a private email with Hans,
^(OP | LC) allowbreak (LC)
is another typesetting rule for Korean,
where OP stands for Openings and LC for Leading Consonants (U+1100 .. U+115F).
In the above output, as U+1161 is non-LC character,
line-breaking should be allowed between U+1161 and U+1102.

Dohyun Kim
___
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
___


Re: [NTG-context] korean

2009-02-04 Thread Dohyun Kim
2009/2/4 Wolfgang Schuster schuster.wolfg...@googlemail.com:
 2009/2/4 Dohyun Kim nomosno...@gmail.com:

 나라의 말이 중국과 달라서 한자로는 % endline space should be honoured

 This is a side effect of the font handling, I used the hang script which
 supports only chinese and removes all spaces from the input (between
 words and at the end of the line).

 You get better results with features=default in the typescript because
 the spaces remain now in the input but ConTeXt makes a line break now
 only at the spaces.


Yes! Much better with default features. Only missing is
allowing line break between characters.

On the other hand, as script tag hang denotes Hangul
according to opentype specification, it would be confusing
to use this name for Chinese typesetting.  See:
http://www.microsoft.com/typography/otspec/scripttags.htm


 I would be better you can provide us better examples, copy and past
 from other texts is not the best solution.


The example provided by Wolfgang and corrected by me seems to be
sufficient for simple testing.  It contains Hangul, Chinese characters,
parentheses, commas, and Latin fullstops.
Only Latin words are missing; so how about this?

나라의 말이 중국과 달라서 한자(chinese characters)로는

Following link is the result compiled with latex under [a5paper] option:
http://people.ktug.or.kr/~nomos/mine/koreantypesettingwithlatex.png

Dohyun Kim
___
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
___


Re: [NTG-context] korean

2009-02-04 Thread Dohyun Kim
2009/2/4 Hans Hagen pra...@wxs.nl:
 Yue Wang wrote:
 Hi, Hans:

 Great work! One comment:
 Line 3 and 4, the second paragraph, the line is too stretched,
 in fact you can break a Korean word anywhere you want, and no
 hyphenation is needed.

 this version inserts a penalty5 and glue0


The result has
- too wide space between Korean char(including Chinese char) and fullstop.
- too wide space between Korean char(including Chinese char) and comma.
- too wide space between Korean char(including Chinese char) and
opening parenthesis.
- too wide space between closing parenthesis and Korean char(including
Chinese char).
- too wide space between opening parenthesis and Korean char(including
Chinese char)
- too wide space between Korean char(including Chinese char) and
closing parenthesis.

Korean typesetting is somewhat different from Chinese or Japanese typesetting.
It has inter-word spaces (ie. glue). So inter-word spaces, fullstops, commas,
and parentheses should be treated as the same as in Latin typesetting,
except allowing line break
 1. between Korean char and opening parentheses
 2. between closing parenthesis and Korean char.
In these cases, glue with big plus or minus stretch is not desirable.

Dohyun Kim
___
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
___


Re: [NTG-context] korean

2009-02-04 Thread Dohyun Kim
2009/2/4 Yue Wang yuleo...@gmail.com:

 Oh, Dohyun, if I said something wrong on Korean's typeface, please
 point out. I am not a native Korean speaker:)


There are many more free Korean fonts.

Unfonts have good (but not excellent, frankly speaking) quality
and are originated from Korean TeX community, so that
Korean TeX users normally use unfonts officially.
Actually, however, they use other commercial or free fonts for
really critical or private purposes.

Moreover, recently, there's a noticeable trend in Korea
for big private companies or local governments to release
free fonts of high quality.  Amongst them, Nanum fonts
released by number one Korean portal site, Naver, are noteworthy.

Serif and Sans series of Nanum fonts:
http://hangeul.naver.com/index.nhn?goto=fonts#fonts

Monospace series of Nanum fonts:
http://dev.naver.com/projects/nanumfont

These fonts are freely redistributable, as far as I know.

I will introduce some more Korean free fonts of quality
later on another occasion.

Dohyun Kim
___
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
___


Re: [NTG-context] korean

2009-02-04 Thread Dohyun Kim
2009/2/4 Hans Hagen pra...@wxs.nl:
 Dohyun Kim wrote:

 2009/2/4 Hans Hagen pra...@wxs.nl:

 Yue Wang wrote:

 Hi, Hans:

 Great work! One comment:
 Line 3 and 4, the second paragraph, the line is too stretched,
 in fact you can break a Korean word anywhere you want, and no
 hyphenation is needed.

 this version inserts a penalty5 and glue0


 The result has
 - too wide space between Korean char(including Chinese char) and fullstop.
 - too wide space between Korean char(including Chinese char) and comma.
 - too wide space between Korean char(including Chinese char) and
 opening parenthesis.
 - too wide space between closing parenthesis and Korean char(including
 Chinese char).
 - too wide space between opening parenthesis and Korean char(including
 Chinese char)
 - too wide space between Korean char(including Chinese char) and
 closing parenthesis.


 these spacings are configurable but keep in mind that when doing
 justification tex will try to distribute according to what is set

 maybe for korean the general space might be larger than normal?


Saying too wide space was my mistake. I mean, in all these cases
no space is desirable. Just allowing line break (withot stretching)
before opening parenthesis and after closing parenthesis will be good enough.
In all other cases, do nothing is what I want.

Dohyun Kim
___
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
___


Re: [NTG-context] korean

2009-02-03 Thread Dohyun Kim
2009/2/4 Wolfgang Schuster schuster.wolfg...@googlemail.com:

 Am 03.02.2009 um 21:27 schrieb Hans Hagen:

 Hi,

 is there someone on this list who has tried korean with mkiv? next week
 taco and i travel to korea (user group meeting) so we'd better know how to
 do korean

 Korean use the same rules for line breaking as chinese but spaces
 in the input are not removed and remain in the output.


Several month ago, I have tried Korean typesetting with MKIV,
but the result was short of satisfactory one.

These are minimum typesetting rule for Korean documents:

``Korean characters'' means here
all Hangul Syllables (U+AC00 .. U+D7A3) plus Chinese Ideographs.

- Spaces between words should be preserved, as Wolfgang said.

- Linebreaking should be allowed between Korean characters.
  We prefer here \penalty50 or \discretionary{}{}{} rather than \hskip.

- Linebreaking is allowed between Korean character and Latin character.
  We prefer here \hskip0pt to make possible hyphenations inside Latin word.

- Kumchik (``Kinsoku'' in Japanese) rule is the same as Chinese or
Japanese typesetting:
  * Linebreaking should not occur after, for example, opening parentheses.
  * Linebreaking should not occur before, for example, closing
parentheses, comma, or fullstop.

That's all.

Best,
Dohyun Kim
___
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
___


Re: [NTG-context] korean

2009-02-03 Thread Dohyun Kim
2009년 2월 4일 (수) 오전 9:25, Wolfgang Schuster
schuster.wolfg...@googlemail.com님의 말:

 나라의 말이 중국과 달라서 한자로
 는 서로 통하지 아니하므로 이런 까
 닭으로 어리석은 백성들이 말하고
 자 하는 바가 있어도 마침내 제뜻
 을 능히 펴지 못하는 사람이 많으
 니라. 내가 이를 불쌍히 여겨 새로
 스물여덟자를 만드나니

나라의 말이 중국과 달라서 한자로는 % endline space should be honoured
서로 통하지 아니하므로 이런 까닭으로
어리석은 백성들이 말하고자
하는 바가 있어도 마침내 제뜻을
능히 펴지 못하는 사람이 많으니라.
내가 이를 불쌍히 여겨 새로
스물여덟자를 만드나니


 아아, 나는 이제야 도 (道) 를 알았도다. 마음이 어두운 자는 이목이 누
 (累) 가 되지 않는다. 이목만을 믿는 자는 보고 듣는 것이 더욱 밝혀져서
 병이 되는 것이다. 이제 내 마부가 발을 말굽에 밟혀서 뒷차에 실리었으
 므로, 나는 드디어 혼자 고삐를 늦추어 강에 띄우고, 무릎을 구부려 발을
 모으고 안장 위에 앉았다. 한번 떨어지면 강이나 물로 땅을 삼고, 물로
 옷을 삼으며, 물로 몸을 삼고, 물로 성정을 삼을 것이다. 이제야 내 마
 음은 한번 떨어질 것을 판단한 터이므로, 내 귓속에 강물 소리가 없어졌
 다. 무릇 아홉 번 건너는데도 걱정이 없어 의자 위에서 좌와 (坐臥) 하고
 기거 (起居) 하는 것 같았다.


아아, 나는 이제야 도(道)를 알았도다. 마음이 어두운 자는 이목이
누(累)가 되지 않는다. 이목만을 믿는 자는 보고 듣는 것이
더욱 밝혀져서 병이 되는 것이다. 이제 내 마부가 발을 말굽에
밟혀서 뒷차에 실리었으므로, 나는 드디어 혼자 고삐를 늦추어
강에 띄우고, 무릎을 구부려 발을 모으고 안장 위에 앉았다.
한번 떨어지면 강이나 물로 땅을 삼고, 물로 옷을 삼으며,
물로 몸을 삼고, 물로 성정을 삼을 것이다. 이제야 내 마음은
한번 떨어질 것을 판단한 터이므로, 내 귓속에 강물 소리가 없어졌다.
무릇 아홉 번 건너는데도 걱정이 없어 의자 위에서 좌와(坐臥)하고
기거(起居)하는 것 같았다.

Korean orthography has rules of
where spaces should be inserted and where not.
So here I proofread Korean texts provided by Wolfgang.

Best,
Dohyun Kim
___
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
___


Re: [NTG-context] MKIV Chinese and English typesetting

2008-03-25 Thread Dohyun Kim
2008/3/25, Yue Wang [EMAIL PROTECTED]:
  Dear Hans and other friends:
  
I am a Chinese user of ConTeXt. Recently, I tried ConTeXt MkIV and
test its Chinese  typesetting. I am very glad to see MkIV can access
my linux OS TTFOTF fonts and give a good face of my article about
lines breaking. But on the bilingual typesetting, such as Chinese
sentences and English words appearance in a article at the same time ,
I found there are no good methods to solve the  problem of  setting
fonts for them respectively. Now I had to handle it in this way:
  



 Well, I am aware of that problem (I think Hans is aware of that
  too). See the relative thread in mailing list archive (Jan 2008, I
  think). I mentioned the problem again in another mail to Hans this
  morning because more messages like this appeared on Chinese TeX
  related web forums these days (It's a good thing, more Chinese TeX
  Gurus love to play ConTeXt and LuaTeX ^_^).

  There are many ways to deal with that problem. in fact, add your \en
  macro into the method.hani() function of  font-otf.lua is a quick and
  dirty hack. But I think there should be other more elegant ways to
  deal with it. perhaps:
  - assign an english font feature to \definefontfeature or
  \definefontsynonym. When define a CJK typefaces, the corresponding
  English typeface can be defined by the user. switch to another font
  when needed (using the similar method as in font-otf.lua).
  - map the CJK part of a Chinese typeface and Latin part of a English
  typeface to one single virtual font, Use this virtual font for
  typesetting.

  Both of them are not hard to do technically compared what had been
  done before.  So maybe we should wake Hans up to continue the CJK
  support? Zhichu Chen and I are eager to help whenever a localization
  problem is occurred.


FYI.  I have recently tried to implement Korean typesetting with LuaTeX,
using the second method you have mentioned, that is virtual font mechanism.
It is, however, not for ConTeXt but for plain TeX, because I am
ignorant about ConTeXt.

http://people.ktug.or.kr/~nomos/mine/luatexko.tex
http://people.ktug.or.kr/~nomos/mine/luatexko.lua
http://people.ktug.or.kr/~nomos/mine/luatextt.lua

On current stage, one of important features missing is supporting
opentype GSUB, which now I am trying to understand how to implement.

For testing, you have to install UnBatang.ttf, the most popular truetype font
for Korean language. You can download this font from
http://kldp.net/frs/download.php/1425/un-fonts-core-1.0.tar.gz
or you may already have it if you use debian or ubuntu linux system.

Then just make a document as follows and compile it with `luatex' command
%
\input luatexko
... some Korean document including english characters ...
\bye
%

I hope my effort could contribute to developing CJK typesetting with LuaTeX.

Dohyun Kim
___
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
___


[NTG-context] please add support for Korean language in unic-cjk.tex

2006-11-22 Thread Dohyun Kim
Hi.

Recently I have tried to support typesetting UTF-8 Korean language
along with context-beta. I have uploaded related files
to a temporary server for your reference (3.5Mb):

http://210.94.201.157/~nomos/KTUG/context-korean-test.tar.gz

But as the current unic-cjk.tex does not cover
Korean Hangul Syllables area and CJK Compatibility Ideographs area,
I have to edit that file every time I upgrade context.
It is so an annoying thing to do it every time
that I suggest adding those areas in unic-cjk.tex file,  like this:

%%% Hangul Syllables
\dostepwiserecurse{172}{215}{1}{\expanded{\defineunicodecommand
{\recurselevel}} {\lookaheaduchar}}
%%% CJK Compatibility Ideographs
\dostepwiserecurse{249}{250}{1}{\expanded{\defineunicodecommand
{\recurselevel}} {\lookaheaduchar}}


Additionally, I here report some possible bugs of context-beta
related to CJK (especially Korean language) support.

First, unintended space is inserted when I change font family.
This disappears if I add a comment sign in \enableunicodefont
command in font-uni.tex.

\def\enableunicodefont#1%
  {\definefontsynonym[\s!Unicode][\getvalue{\??uc#1\c!file}]%
   \def\unicodescale {\getvalue{\??uc#1\c!scale}}%
   \def\unicodeheight{\getvalue{\??uc#1\c!height}}%
   \def\unicodedepth {\getvalue{\??uc#1\c!depth}}%
   \def\unicodedigits{\getvalue{\??uc#1\c!conversion}}%
   \def\handleunicodeglyph   {\getvalue{\??uc#1\c!command}}%
   \doifnot\currentregime{utf}{\enableregime[unicode]}%
   % the following \relax's are realy needed
   \doifvalue{\??uc#1\c!interlinespace}\v!yes
  \setupinterlinespace\relax
   \doifvalue{\??uc#1\c!strut}\v!yes
  {\setunicodestrut\unicodeheight\unicodedepth}% - HERE
  {\resetunicodestrut}%
   \getvalue{\??uc#1\c!commands}\relax}


Secondly, to deal with special commands in pdf bookmarks,
\simplifycommands should be added to \sanitizePDFuniencoding
command in spec-tst.tex.

\long\def\sanitizePDFuniencoding#1\to#2%
  {\enablePDFunicrlf
\simplifycommands  % - HERE
   \let\unicodechar\relax % prevent further expansion
   \retainlccodes\lccode32=255 % slooow
   \lowercasestring\PDFunicodetrigger#1\to#2%
   \edef#2{\expandafter\doPDFuni#2\empty\empty}} % slooow


Thirdly, \definefileinsertion{tpd}{mps} in spec-dpx.tex
seems to be a typo. I think this should be corrected as follows:

\definefileinsertion{dpx}{mps}


In fact, as an unsubscribed user I have posted a similar message
to the context mailinglist a few weeks ago . But I did not obtain
any response then. Now being subscribed, I repost it.

Best Regards,
-- 
Dohyun Kim
http://people.ktug.or.kr/~nomos/
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context


[NTG-context] bugs found while trying to support utf-8 Korean Hangul under ConTeXt

2006-10-21 Thread Dohyun Kim
Hi,

http://210.94.201.157/~nomos/KTUG/context-korean-test.tar.gz (3.4Mb)

Recently I have tried to support typesetting UTF-8 Korean document
under ConTeXt.

In the course of that trying, I found some possible bugs of recent
ConTeXt beta.
You can see most of the bugs (or missing features) I found in the file
named `testme.tex',
which is contained in the tarball linked above.

For those who do not want to download that large tarball,
I here replicate those bugs or missing features:

%%%
% should be added to unic-cjk.tex
% Hangul Syllables
\dostepwiserecurse{172}{215}{1}{\expanded{\defineunicodecommand {\recurselevel}}
  {\lookaheaduchar}}
% CJK Compatibility Ideographs
\dostepwiserecurse{249}{250}{1}{\expanded{\defineunicodecommand {\recurselevel}}
  {\lookaheaduchar}}


%%%
% modify \enableunicodefont in font-uni.tex
\def\enableunicodefont#1%
  {\definefontsynonym[\s!Unicode][\getvalue{\??uc#1\c!file}]%
   \def\unicodescale {\getvalue{\??uc#1\c!scale}}%
   \def\unicodeheight{\getvalue{\??uc#1\c!height}}%
   \def\unicodedepth {\getvalue{\??uc#1\c!depth}}%
   \def\unicodedigits{\getvalue{\??uc#1\c!conversion}}%
   \def\handleunicodeglyph   {\getvalue{\??uc#1\c!command}}%
   \doifnot\currentregime{utf}{\enableregime[unicode]}%
   % the following \relax's are realy needed
   \doifvalue{\??uc#1\c!interlinespace}\v!yes
  \setupinterlinespace\relax
   \doifvalue{\??uc#1\c!strut}\v!yes
  {\setunicodestrut\unicodeheight\unicodedepth}% - `%' inserted by nomos
  {\resetunicodestrut}%
   \getvalue{\??uc#1\c!commands}\relax}


%%%
% modify \sanitizePDFuniencoding in spec-tst.tex
\long\def\sanitizePDFuniencoding#1\to#2%
  {\enablePDFunicrlf
   \simplifycommands % - this line inserted by nomos
   \let\unicodechar\relax % prevent further expansion
   \retainlccodes\lccode32=255 % slooow
   \lowercasestring\PDFunicodetrigger#1\to#2%
   \edef#2{\expandafter\doPDFuni#2\empty\empty}} % slooow


%%%
% modify mps file insertion code in spec-dpx.tex
\definefileinsertion{dpx}{mps}   % tpd - dpx modified by nomos
  {\hbox
 {\convertMPtoPDF\@@DriverImageFile{1}{1}%
  \global\let\PDFimagereference\empty}}


Certainly, the last is not problem confined to Hangul typesetting.
As you know, however, CJK peoples do use heavily dvipdfmx to obtain PDF.

Anyway, I hope these four files be modified in the near future.

In addition, when I compiled LaTeX2ConTeXt.tex by Berend de Boer
( http://www.berenddeboer.net/tex/LaTeX2ConTeXt.tex ),
I found there being inserted unintended large vertical whitespace
in page 27 of resulting PDF.
Though it seems to be a bug related to \setupbackground,
I could not find the cause of problem as the code related to that command
is too complicated for me.

-- 
Dohyun Kim
http://people.ktug.or.kr/~nomos/
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context