strange behavior of startbackground

strange behavior of startbackground

[Xiao Jianfeng]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Hello,

I came across a problem when I was trying to compile my tex file.
The attached file is an example.

I have to process Chinese, so "\loadmapfile[gbk]" and
"\usemodule[chinese]" are essential.

I'm using the lastest release of ConTeXt.
ConText ver:2005.12.01, texExec 5.4.3, to be exact.
And I use "texmfstart texexec.pl --autopdf --pdf test2.tex" to compile
 my source file.

The problem is there is enough space in page 2 for the words between
\startbackground and \stopbackground, but the background block was put
 on page 3 with most of the page 2 was left blank.

And there is another small problem, the command \setupindenting[medium]
didn't work.

Thanks a lot.

xiaojf


[-- Attachment #2: test2.tex --]
[-- Type: text/plain, Size: 1285 bytes --]

%interface=en output=pdftex 
\loadmapfile[gbk]
\usemodule[chinese]
\setuppagenumbering[location=inright]
\setupbodyfont[lbr,12pt]
\setupindenting[medium]
\setupcolors[state=start]
\setupbackground[state=start,background=screen,cornor=round]
\setupinterlinespace[medium]
%---------------------------------------------------------------------

\starttext
\input knuth

\input knuth
%---------------------------------------------------------------------

\subject{Introduction}

word word word word word word word word word word word word.
\startitemize[n]
 \item word, word word word word word word word word word word 
       word word word word word word word word.
 \item word, word word word word word word word word word
       word word word word word word word word-word word 
       word word word word word word word word word word.
\stopitemize

Water along with small polar molecules and lipophilic drugs are konwn to corss
the barrier. Larger polar molecules and hydrophilic(?hydrophyllic) organic 
molecules, including plasma preoteins(Ѫ½¬µ°°×), do not penetrate well.


\startbackground
word word word word word word word word word word word word word word word word 
word word word word word word word word
\stopbackground
\stoptext

[-- Attachment #3: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: strange behavior of startbackground

[Xiao Jianfeng]

Xiao Jianfeng wrote:

>Hello,
>
>I came across a problem when I was trying to compile my tex file.
>The attached file is an example.
>
>I have to process Chinese, so "\loadmapfile[gbk]" and
>"\usemodule[chinese]" are essential.
>
>I'm using the lastest release of ConTeXt.
>ConText ver:2005.12.01, texExec 5.4.3, to be exact.
>And I use "texmfstart texexec.pl --autopdf --pdf test2.tex" to compile
> my source file.
>
>The problem is there is enough space in page 2 for the words between
>\startbackground and \stopbackground, but the background block was put
> on page 3 with most of the page 2 was left blank.
>
>And there is another small problem, the command \setupindenting[medium]
>didn't work.
>
>Thanks a lot.
>
>xiaojf
>
>  
>
>------------------------------------------------------------------------
>
>%interface=en output=pdftex 
>\loadmapfile[gbk]
>\usemodule[chinese]
>\setuppagenumbering[location=inright]
>\setupbodyfont[lbr,12pt]
>\setupindenting[medium]
>\setupcolors[state=start]
>\setupbackground[state=start,background=screen,cornor=round]
>\setupinterlinespace[medium]
>%---------------------------------------------------------------------
>
>\starttext
>\input knuth
>
>\input knuth
>%---------------------------------------------------------------------
>
>\subject{Introduction}
>
>word word word word word word word word word word word word.
>\startitemize[n]
> \item word, word word word word word word word word word word 
>       word word word word word word word word.
> \item word, word word word word word word word word word
>       word word word word word word word word-word word 
>       word word word word word word word word word word.
>\stopitemize
>
>Water along with small polar molecules and lipophilic drugs are konwn to corss
>the barrier. Larger polar molecules and hydrophilic(?hydrophyllic) organic 
>molecules, including plasma preoteins(血浆蛋白), do not penetrate well.
>  
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If I remove the Chinese characters on this line, the next part of the
file will
be put appropriately on page 2.

>
>\startbackground
>word word word word word word word word word word word word word word word word 
>word word word word word word word word
>\stopbackground
>\stoptext
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>ntg-context mailing list
>ntg-context@ntg.nl
>http://www.ntg.nl/mailman/listinfo/ntg-context
>  
>

Re: strange behavior of startbackground

[Xiao Jianfeng]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

I am trying to send the result PDF file created on my system separately,
since I'm not sure if the mailing list can receive a attached file the
size of which is 38K.


[-- Attachment #2: test2.pdf --]
[-- Type: application/pdf, Size: 38829 bytes --]

[-- Attachment #3: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: strange behavior of startbackground

[Xiao Jianfeng]

Xiao Jianfeng wrote:

>Hello,
>
>I came across a problem when I was trying to compile my tex file.
>The attached file is an example.
>
>I have to process Chinese, so "\loadmapfile[gbk]" and
>"\usemodule[chinese]" are essential.
>
>I'm using the lastest release of ConTeXt.
>ConText ver:2005.12.01, texExec 5.4.3, to be exact.
>And I use "texmfstart texexec.pl --autopdf --pdf test2.tex" to compile
> my source file.
>
>The problem is there is enough space in page 2 for the words between
>\startbackground and \stopbackground, but the background block was put
> on page 3 with most of the page 2 was left blank.
>
>And there is another small problem, the command \setupindenting[medium]
>didn't work.
>
>Thanks a lot.
>
>xiaojf
>
>  
>
>------------------------------------------------------------------------
>
>%interface=en output=pdftex 
>\loadmapfile[gbk]
>\usemodule[chinese]
>\setuppagenumbering[location=inright]
>\setupbodyfont[lbr,12pt]
>\setupindenting[medium]
>\setupcolors[state=start]
>\setupbackground[state=start,background=screen,cornor=round]
>\setupinterlinespace[medium]
>%---------------------------------------------------------------------
>
>\starttext
>\input knuth
>
>\input knuth
>%---------------------------------------------------------------------
>
>\subject{Introduction}
>
>word word word word word word word word word word word word.
>\startitemize[n]
> \item word, word word word word word word word word word word 
>       word word word word word word word word.
> \item word, word word word word word word word word word
>       word word word word word word word word-word word 
>       word word word word word word word word word word.
>\stopitemize
>
>Water along with small polar molecules and lipophilic drugs are konwn to corss
>the barrier. Larger polar molecules and hydrophilic(?hydrophyllic) organic 
>molecules, including plasma preoteins(血浆蛋白), do not penetrate well.
>
>
>\startbackground
>word word word word word word word word word word word word word word word word 
>word word word word word word word word
>\stopbackground
>\stoptext
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>ntg-context mailing list
>ntg-context@ntg.nl
>http://www.ntg.nl/mailman/listinfo/ntg-context
>  
>
I have tried to attached the PDF file created on my system, so people
can understand my problem easily.
But the file size is a little big(38K), and it is being held until the
list moderator can review it for approval -_-

Re: strange behavior of startbackground

[Taco Hoekwater]

Xiao Jianfeng wrote:
> 
> And there is another small problem, the command \setupindenting[medium]
> didn't work.

I've written a faq entry for that:

  http://wiki.contextgarden.net/FAQ

Cheers, Taco

Re: strange behavior of startbackground

[Hans Hagen]

Xiao Jianfeng wrote:

>Hello,
>
>I came across a problem when I was trying to compile my tex file.
>The attached file is an example.
>
>I have to process Chinese, so "\loadmapfile[gbk]" and
>"\usemodule[chinese]" are essential.
>
>I'm using the lastest release of ConTeXt.
>ConText ver:2005.12.01, texExec 5.4.3, to be exact.
>And I use "texmfstart texexec.pl --autopdf --pdf test2.tex" to compile
> my source file.
>
>The problem is there is enough space in page 2 for the words between
>\startbackground and \stopbackground, but the background block was put
> on page 3 with most of the page 2 was left blank.
>
>And there is another small problem, the command \setupindenting[medium]
>didn't work.
>  
>
\setupindenting[medium,yes] % yes enables it

Concerning the background ...

  \setupinterlinespace[medium]

is different from for instance

  \setupinterlinespace[line=20pt]

The first case is used for a (more or less) temporary increase and 
leaves \lineheight untouched; this means that lineheight related 
settings stay as they are, which is intended behavour: consider for 
instance a situation where one wants to have a draft copy with a larger 
line distance but at the same time wants to keep (lineheight related) 
graphics untouched.

In your case, you want it as a stye/document property, and so it's 
better to use the second method.

Now, concerning backgrounds: i need to fix that for the first case (use 
\openlineheight instead of lineheight in calculations) [you may enter an 
bug entry in the collector]

For the moment use \setupinterlinespace[line=20pt] or something like that

Hans

Re: strange behavior of startbackground

[Hans Hagen]

Xiao Jianfeng wrote:

>>I have to process Chinese, so "\loadmapfile[gbk]" and
>>"\usemodule[chinese]" are essential.
>>    
>>
i had to tweak my gbsong map file for names of encodings files

what is todays standard naming scheme in china?

how about making a zip with map, enc and tfm files for the most common 
fonts?

Hans

Re: strange behavior of startbackground

[Xiao Jianfeng]

Hans Hagen wrote:

> Xiao Jianfeng wrote:
>
>> Hello,
>>
>> I came across a problem when I was trying to compile my tex file.
>> The attached file is an example.
>>
>> I have to process Chinese, so "\loadmapfile[gbk]" and
>> "\usemodule[chinese]" are essential.
>>
>> I'm using the lastest release of ConTeXt.
>> ConText ver:2005.12.01, texExec 5.4.3, to be exact.
>> And I use "texmfstart texexec.pl --autopdf --pdf test2.tex" to compile
>> my source file.
>>
>> The problem is there is enough space in page 2 for the words between
>> \startbackground and \stopbackground, but the background block was put
>> on page 3 with most of the page 2 was left blank.
>>
>> And there is another small problem, the command \setupindenting[medium]
>> didn't work.
>>  
>>
> \setupindenting[medium,yes] % yes enables it

  Thanks, Hans!
 
  This command does enables indentation except the first line after a 
\subject or \subsubject.
  Is this a bug or ConTeXt was designed to do so ?

  One more question, can I set up indenting for English and Chinese 
separately ? The firstly line
  of every paragraph needs to be indented usually in China, but in 
English it doesn't.

>
> Concerning the background ...
>
>  \setupinterlinespace[medium]
>
> is different from for instance
>
>  \setupinterlinespace[line=20pt]
>
   This solved my problem, thanks again.

> The first case is used for a (more or less) temporary increase and 
> leaves \lineheight untouched; this means that lineheight related 
> settings stay as they are, which is intended behavour: consider for 
> instance a situation where one wants to have a draft copy with a 
> larger line distance but at the same time wants to keep (lineheight 
> related) graphics untouched.
>
> In your case, you want it as a stye/document property, and so it's 
> better to use the second method.
>
> Now, concerning backgrounds: i need to fix that for the first case 
> (use \openlineheight instead of lineheight in calculations) [you may 
> enter an bug entry in the collector]
>
> For the moment use \setupinterlinespace[line=20pt] or something like that
>
> Hans
>
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>

Re: strange behavior of startbackground

[Xiao Jianfeng]

Hans Hagen wrote:

> Xiao Jianfeng wrote:
>
>>> I have to process Chinese, so "\loadmapfile[gbk]" and
>>> "\usemodule[chinese]" are essential.
>>>   
>>
> i had to tweak my gbsong map file for names of encodings files
>
> what is todays standard naming scheme in china?


  I don't quite understand what does the "naming scheme " mean, I'm not 
an expert in TeXing.

  Most TeX users using LaTeX coupled with CJK or CCT to typeset Chinese. 
This does a good job
  in processing Chinese, and it can produce PDF files in which the 
Chinese characters can be copyed
  and pasted to the other place.

  I'll find someone to ask what is todays standard naming scheme about 
TeX in china.
  However, it may take some time before I can get an answer.

>
> how about making a zip with map, enc and tfm files for the most common 
> fonts?

  I think it's a good idea.

  I've download essential map, enc and tfm files for Chinese from the 
internet, do you need a copy of them ?

>
> Hans
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>

Re: strange behavior of startbackground

[Hans Hagen]

Xiao Jianfeng wrote:

> Hans Hagen wrote:
>
>> Xiao Jianfeng wrote:
>>
>>>> I have to process Chinese, so "\loadmapfile[gbk]" and
>>>> "\usemodule[chinese]" are essential.
>>>>   
>>>
>>>
>> i had to tweak my gbsong map file for names of encodings files
>>
>> what is todays standard naming scheme in china?
>
>
>
>  I don't quite understand what does the "naming scheme " mean, I'm not 
> an expert in TeXing.

well, sometime i get files that assume gbk-xx.enc and other times such 
encoding files are referenced as gbxxxx.enc

long ago i got metrics and enc/map files from Wang Lei (we needed to 
generate things ourselves with rather buggy programs) but in the 
meantime chinese tex support may have changed

>  Most TeX users using LaTeX coupled with CJK or CCT to typeset 
> Chinese. This does a good job
>  in processing Chinese, and it can produce PDF files in which the 
> Chinese characters can be copyed
>  and pasted to the other place.
>
>  I'll find someone to ask what is todays standard naming scheme about 
> TeX in china.
>  However, it may take some time before I can get an answer.

ok

>
>>
>> how about making a zip with map, enc and tfm files for the most 
>> common fonts?
>
>
>  I think it's a good idea.
>
>  I've download essential map, enc and tfm files for Chinese from the 
> internet, do you need a copy of them ?

ok; maybe you should put that link in the wiki (a page on chinese or so)

Hans

Re: strange behavior of startbackground

[Hans Hagen]

Xiao Jianfeng wrote:

> Hans Hagen wrote:
>
>> Xiao Jianfeng wrote:
>>
>>> Hello,
>>>
>>> I came across a problem when I was trying to compile my tex file.
>>> The attached file is an example.
>>>
>>> I have to process Chinese, so "\loadmapfile[gbk]" and
>>> "\usemodule[chinese]" are essential.
>>>
>>> I'm using the lastest release of ConTeXt.
>>> ConText ver:2005.12.01, texExec 5.4.3, to be exact.
>>> And I use "texmfstart texexec.pl --autopdf --pdf test2.tex" to compile
>>> my source file.
>>>
>>> The problem is there is enough space in page 2 for the words between
>>> \startbackground and \stopbackground, but the background block was put
>>> on page 3 with most of the page 2 was left blank.
>>>
>>> And there is another small problem, the command \setupindenting[medium]
>>> didn't work.
>>>  
>>>
>> \setupindenting[medium,yes] % yes enables it
>
>
>  Thanks, Hans!
>
>  This command does enables indentation except the first line after a 
> \subject or \subsubject.
>  Is this a bug or ConTeXt was designed to do so ?

by design

you can set the 'indentnext' key to 'yes' (in setuphead)

>
>  One more question, can I set up indenting for English and Chinese 
> separately ? The firstly line
>  of every paragraph needs to be indented usually in China, but in 
> English it doesn't.

you can say \noindenting before paragraphs that don't need it

Hans

Re: strange behavior of startbackground

[Xiao Jianfeng]

Hans Hagen wrote:

>>> i had to tweak my gbsong map file for names of encodings files
>>>
>>> what is todays standard naming scheme in china?
>>
>>
>>
>>
>>  I don't quite understand what does the "naming scheme " mean, I'm 
>> not an expert in TeXing.
>
>
> well, sometime i get files that assume gbk-xx.enc and other times such 
> encoding files are referenced as gbxxxx.enc
>
> long ago i got metrics and enc/map files from Wang Lei (we needed to 
> generate things ourselves with rather buggy programs) but in the 
> meantime chinese tex support may have changed

  Wang Lei is an expert in China TeX community. Can you  get touch with 
him ?
  I think his answer to your question should be authoritative.

>>  I think it's a good idea.
>>
>>  I've download essential map, enc and tfm files for Chinese from the 
>> internet, do you need a copy of them ?
>
>
> ok; maybe you should put that link in the wiki (a page on chinese or so)

 OK

>
> Hans
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>

Re: strange behavior of startbackground

[Xiao Jianfeng]

>>
>> ok; maybe you should put that link in the wiki (a page on chinese or so)
>
>
> OK
>
>>
>> Hans
>
 I have created an entry on the wiki about how to get essential files 
and how to configure ConTeXt to support Chinese.

 The address is http://wiki.contextgarden.net/User:Xiaojf.

 I don't know where is the proper place to put this entry, somebody may 
want to move it to the right place.

Regards,

xiaojf

Re: strange behavior of startbackground

[Xiao Jianfeng]

>>
>> ok; maybe you should put that link in the wiki (a page on chinese or so)
>
>
> OK
>
>>
>> Hans
>
 I have created an entry on the wiki about how to get essential files 
and how to configure ConTeXt to support Chinese.

 The address is http://wiki.contextgarden.net/User:Xiaojf.

 I don't know where is the proper place to put this entry, somebody may 
want to move it to the right place.

Regards,

xiaojf

Re: strange behavior of startbackground

[Patrick Gundlach]

Hi,

>  I have created an entry on the wiki about how to get essential files
>  and how to configure ConTeXt to support Chinese.
>
>  The address is http://wiki.contextgarden.net/User:Xiaojf.
>
>  I don't know where is the proper place to put this entry, somebody
>  may want to move it to the right place.

Somebody was so kind to put it at
http://wiki.contextgarden.net/Chinese so I have deleted the duplicate
on your user page. 

Patrick
-- 
ConTeXt wiki and more: http://contextgarden.net

Re: Chinese (was:Re: strange behavior of startbackground)

[Tobias Burnus]

Hi,

Patrick Gundlach wrote:
> Somebody was so kind to put it at
> http://wiki.contextgarden.net/Chinese so I have deleted the duplicate
> on your user page. 
>   
I tried the receipe there, but with no real success.
Seemingly the UTF-8 encoding makes some trouble - I get either errors or 
the wrong characters.

Any ideas what could be the problem? (using 2005.12.01)

* * *

If I paste the example from the WIKI and save it as UTF-8 into a .tex 
file, tex tries to get
|  Running mktextfm gbsong80,
however and no gbsong80.tmf exists

If I delete all but the first character, texexec shows:

! Use of \dohandleunicodeflowglyph doesn't match its definition.
<recently read> s

<inserted text> \s
                  toptext
<argument> \stoptext

\handleunicodeflowglyph ...ttoken \@EA `\string #2
                                                  \relax
l.7  \stoptext


Tobias

Re: Chinese

[Tobias Burnus]

Hi,

Tobias Burnus wrote:
> Seemingly the UTF-8 encoding makes some trouble - I get either errors 
> or the wrong characters.
Ok, I played around a bit more:
\usemodule[chinese]
\enableregime[utf]
...
Hä? 中文？

Prints as "Hä? ***" (* denotes black boxes).

Whereas
\enableregime[utf] % or without this line
\usemodule[chinese]
prints "H盲? ***" (* denotes three other characters which are not 中文？)

In addition I get:
! Paragraph ended before \handleunicodeflowglyph was complete.

Using \startitemize[c] or \placefigure{} with \mainlanguage[cn] shows 
the proper characters.

Any ideas? Looking at 
http://www.pragma-ade.com/general/manuals/mchinese.pdf one seems to be 
able to simply mix European and Chinese letters; ok using {\language[de] 
Hä}{\language[cn]中文} I can combine them (if I wouldn't get an error at 
'}'.

Tobias

PS: ConTeXt live at ConTeXtgarden does not like chinese at all; the 
transcript shows:
! Misplaced alignment tab character &.
l.6 &
     #36825;里什么饮料也没有...

Re: Chinese

[Patrick Gundlach]

[...]

> PS: ConTeXt live at ConTeXtgarden does not like chinese at all; the
> transcript shows:
> ! Misplaced alignment tab character &.
> l.6 &
>      #36825;里什么饮料也没有...

try again next week. I have this on my to do list.

Patrick
-- 
ConTeXt wiki and more: http://contextgarden.net

Re: Chinese

[Xiao Jianfeng]

Tobias Burnus wrote:

> Hi,
>
> Tobias Burnus wrote:
>
>> Seemingly the UTF-8 encoding makes some trouble - I get either errors 
>> or the wrong characters.
>
> Ok, I played around a bit more:
> \usemodule[chinese]
> \enableregime[utf]
> ...
> Hä? 中文？
>
> Prints as "Hä? ***" (* denotes black boxes).
>
> Whereas
> \enableregime[utf] % or without this line
> \usemodule[chinese]
> prints "H盲? ***" (* denotes three other characters which are not 中文？)
>
> In addition I get:
> ! Paragraph ended before \handleunicodeflowglyph was complete.
>
> Using \startitemize[c] or \placefigure{} with \mainlanguage[cn] shows 
> the proper characters.
>
> Any ideas? Looking at 
> http://www.pragma-ade.com/general/manuals/mchinese.pdf one seems to be 
> able to simply mix European and Chinese letters; ok using 
> {\language[de] Hä}{\language[cn]中文} I can combine them (if I 
> wouldn't get an error at '}'.
>
> Tobias
>
> PS: ConTeXt live at ConTeXtgarden does not like chinese at all; the 
> transcript shows:
> ! Misplaced alignment tab character &.
> l.6 &
>     
> #36825;里什么饮料也没有... 
>
>
>
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>
Maybe it is beacuse of the encoding of your .tex  file.
The encoding of my tex source file is cp936 and I edit with gvim.
ConTeXt compiles OK when processing Chinese. I din't use 
\enableregime[utf] or \language[cn] to typeset Chinese.

Regards,
xiaojf

Re: Chinese

[Tobias Burnus]

Hi,

Xiao Jianfeng wrote:
> Maybe it is beacuse of the encoding of your .tex  file.
> The encoding of my tex source file is cp936 and I edit with gvim.
> ConTeXt compiles OK when processing Chinese. I din't use 
> \enableregime[utf] or \language[cn] to typeset Chinese.
Ok this works. Another possibility is to use the script by Lutz (see 
link in the wiki) which converts UTF8 to gbk.
However, both solutions have the drawback that e.g. "ä" does not get 
typset (there is no ä in gbk).

What would be needed to get UTF-8 input running with Chinese?

Tobias

Re: Chinese

[Xiao Jianfeng]

Hi,

Tobias Burnus wrote:

> Hi,
>
> Xiao Jianfeng wrote:
>
>> Maybe it is beacuse of the encoding of your .tex  file.
>> The encoding of my tex source file is cp936 and I edit with gvim.
>> ConTeXt compiles OK when processing Chinese. I din't use 
>> \enableregime[utf] or \language[cn] to typeset Chinese.
>
> Ok this works. Another possibility is to use the script by Lutz (see 
> link in the wiki) which converts UTF8 to gbk.
> However, both solutions have the drawback that e.g. "ä" does not get 
> typset (there is no ä in gbk).
>
> What would be needed to get UTF-8 input running with Chinese?
>
> Tobias
>
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>
If you use vim to edit your tex file, maybe you can try "set 
encoding=utf8", then save and compile.
As far as I know, GBK is compatible with unicode.

I'm not sure if it works or not. I don't konw too much about encoding.

Regards,
xiaojf

Re: Chinese

[Tobias Burnus]

Hi,

Xiao Jianfeng wrote:
>> What would be needed to get UTF-8 input running with Chinese?
> If you use vim to edit your tex file, maybe you can try "set 
> encoding=utf8", then save and compile.
> As far as I know, GBK is compatible with unicode.
No, that does not work - that is the reason I started this mail thread.
You get the wrong characters and you may get some TeX errors.
(And that is the reason Lutz wrote a UTF-8 to GBK converted.)

Tobias

Re: Chinese

[Xiao Jianfeng]

Tobias Burnus wrote:

> Hi,
>
> Xiao Jianfeng wrote:
>
>>> What would be needed to get UTF-8 input running with Chinese?
>>
>> If you use vim to edit your tex file, maybe you can try "set 
>> encoding=utf8", then save and compile.
>> As far as I know, GBK is compatible with unicode.
>
> No, that does not work - that is the reason I started this mail thread.
> You get the wrong characters and you may get some TeX errors.
> (And that is the reason Lutz wrote a UTF-8 to GBK converted.)
>
> Tobias
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>
So, maybe the problem has something to do with you input method.
How do you input Chinese in your system ?

Re: Chinese

[Xiao Jianfeng]

Tobias Burnus wrote:

> Hi,
>
> Xiao Jianfeng wrote:
>
>>> What would be needed to get UTF-8 input running with Chinese?
>>
>> If you use vim to edit your tex file, maybe you can try "set 
>> encoding=utf8", then save and compile.
>> As far as I know, GBK is compatible with unicode.
>
> No, that does not work - that is the reason I started this mail thread.
> You get the wrong characters and you may get some TeX errors.
> (And that is the reason Lutz wrote a UTF-8 to GBK converted.)
>
> Tobias
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>
What is the value of your environment variables about LC_CTYPE and LANG ?

Re: Chinese

[Adam Lindsay]

Tobias Burnus wrote:
> Hi,
> 
> Xiao Jianfeng wrote:
> 
>>> What would be needed to get UTF-8 input running with Chinese?
>>
>> If you use vim to edit your tex file, maybe you can try "set 
>> encoding=utf8", then save and compile.
>> As far as I know, GBK is compatible with unicode.
> 
> No, that does not work - that is the reason I started this mail thread.
> You get the wrong characters and you may get some TeX errors.
> (And that is the reason Lutz wrote a UTF-8 to GBK converted.)

Hmm, I suspect that some remix between my old (deprecated) Libertine in 
ConTeXt recipe and the ttf2tfm automatic unicode splitting would have 
some positive effects.

(I would discourage using that recipe for alphabetic (incl Roman) 
Unicode fonts because it blows away any kerning that would happen 
between unicode blocks. Is there less kerning among CJK fonts? I would 
expect so.)

Thinking aloud, you'd probably want to include some language-switching 
commands, to mediate between the calling of unicode fonts for un-named 
CJK glyphs (just raw conversion from Unicode to font switch + glyph 
number) to named roman (and other alphabetic) glyphs (conversion from 
UTF-8 to named glyphs to font+glyph, which retains kerning where it can).

I know it's sketchy and vague, but have a look inside font-uni. It's not 
the most complicated file in the distro.

adam
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Adam T. Lindsay, Computing Dept.     atl@comp.lancs.ac.uk
  Lancaster University, InfoLab21        +44(0)1524/510.514
  Lancaster, LA1 4WA, UK             Fax:+44(0)1524/510.492
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Chinese

[Tobias Burnus]

Hi,

Xiao Jianfeng wrote:
> What is the value of your environment variables about LC_CTYPE and LANG ?
Well, I use SCIM to input the characters and my locale is de_DE.UTF-8.
As the input works everywhere (OpenOffice, vim in Xterm, gvim etc.) I'm 
positiv that the problem is the lacking support of UTF-8 encoding of 
Chinese in ConTeXt and that this is not a problem of the encoding being 
wrong.

Looking at the cp936 to Unicode table 
(http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT) 
one sees that they are not the same.

A rough big5 to Unicode table can be found at 
http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT


Tobias

Re: Chinese

[Richard Gabriel]

[-- Attachment #1.1: Type: text/plain, Size: 2726 bytes --]

Hi guys,

I can confirm that the UTF-8 input doesn't work for me too. 
If I convert the file info GBK (CP936), it works fine [I suggest to use the 'iconv' utility for the conversion :-)].

I tested the UTF-8 output the followin ways:

1) 
\enableregime[utf]
\usemodule[chinese]

Processing a file with this setup ends with an error:

--- cut ---

kpathsea: Running mktextfm gbsong80
mktextfm: Could not map typeface abbreviation bs for gbsong80.
mktextfm: Need to update c:/WinApp/TeXLive/texmf-dist/fonts/map/fontname/special
.map?
mktextfm: Running mf "\mode:=ljfour; mag:=1; nonstopmode; input gbsong80"
This is METAFONT, Version 2.71828 (Web2c 7.5.5)

kpathsea: Running mktexmf gbsong80
mktexmf: empty or non-existent rootfile!
! I can't find file `gbsong80'.
<*> ...ljfour; mag:=1; nonstopmode; input gbsong80

Please type another input file name
! Emergency stop.
<*> ...ljfour; mag:=1; nonstopmode; input gbsong80

Transcript written on mfput.log.
mktextfm: warning: can't open log file gbsong80.log.
mktextfm: `mf "\mode:=ljfour; mag:=1; nonstopmode; input gbsong80"' failed.
kpathsea: Appending font creation commands to missfont.log.
! Font \unicodefont=gbsong80 at 24.88806pt not loadable: Metric (TFM) file not
found.

--- cut ---
  
I cannot figure out why it wants "gbsong80" when the encoding vector set starts from the 0x81 offset. 
Maybe some error in the UTF mapping?


2)
\usemodule[chinese]
  \enableregime[utf]
  
No error, but not output!
The PDF contains only black squares instead of glyphs.
The log shows that no fonts were used at all!

-Richard


  _____  

From: Xiao Jianfeng [mailto:fdu.xiaojf@gmail.com]
To: mailing list for ConTeXt users [mailto:ntg-context@ntg.nl]
Sent: Fri, 09 Dec 2005 15:24:22 +0100
Subject: Re: [NTG-context] Chinese

Tobias Burnus wrote:

> Hi,
>
> Xiao Jianfeng wrote:
>
>>> What would be needed to get UTF-8 input running with Chinese?
>>
>> If you use vim to edit your tex file, maybe you can try "set 
>> encoding=utf8", then save and compile.
>> As far as I know, GBK is compatible with unicode.
>
> No, that does not work - that is the reason I started this mail thread.
> You get the wrong characters and you may get some TeX errors.
> (And that is the reason Lutz wrote a UTF-8 to GBK converted.)
>
> Tobias
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>
What is the value of your environment variables about LC_CTYPE and LANG ?

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
  

[-- Attachment #1.2: Type: text/html, Size: 3652 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: Chinese

[Tobias Burnus]

Hi,

Adam Lindsay wrote:
> Is there less kerning among CJK fonts? I would expect so.
Classically any Chinese character has exactly the same width, which is 
the same as the height (square). Nowadays some are taller than wide. I'm 
quite certain that there is hardly any Chinese font with kerning as this 
would break the grid.

> Thinking aloud, you'd probably want to include some language-switching 
> commands, to mediate between the calling of unicode fonts for un-named 
> CJK glyphs (just raw conversion from Unicode to font switch + glyph 
> number) to named roman (and other alphabetic) glyphs (conversion from 
> UTF-8 to named glyphs to font+glyph, which retains kerning where it can).
Well, I think one uses most of the time different fonts for Chinese and 
non-CJK texts as many Chinese fonts don't include that many roman 
letters (at least the ones quoted at 
http://wiki.contextgarden.net/Chinese miss the ß and ä).

Tobias

Re: Chinese

[Hans Hagen]

Tobias Burnus wrote:

> Hi,
>
> Adam Lindsay wrote:
>
>> Is there less kerning among CJK fonts? I would expect so.
>
> Classically any Chinese character has exactly the same width, which is 
> the same as the height (square). Nowadays some are taller than wide. 
> I'm quite certain that there is hardly any Chinese font with kerning 
> as this would break the grid.
>
>> Thinking aloud, you'd probably want to include some 
>> language-switching commands, to mediate between the calling of 
>> unicode fonts for un-named CJK glyphs (just raw conversion from 
>> Unicode to font switch + glyph number) to named roman (and other 
>> alphabetic) glyphs (conversion from UTF-8 to named glyphs to 
>> font+glyph, which retains kerning where it can).
>
> Well, I think one uses most of the time different fonts for Chinese 
> and non-CJK texts as many Chinese fonts don't include that many roman 
> letters (at least the ones quoted at 
> http://wiki.contextgarden.net/Chinese miss the ß and ä).

if there is a utf-8 mapping for chinese, then th eother chars can come 
from the main text font

Hans

Re: Chinese

[Hans Hagen]

Richard Gabriel wrote:

> Hi guys,
>
> I can confirm that the UTF-8 input doesn't work for me too.
> If I convert the file info GBK (CP936), it works fine [I suggest to 
> use the 'iconv' utility for the conversion :-)].
>
> I tested the UTF-8 output the followin ways:
>
> 1)
> \enableregime[utf]
> \usemodule[chinese]
>

chinese is not yet defined in utf so if you want that, we need to do it

now, since the chinese remapping stuff is rather complex, the best 
method is to consider a dedicated mechanism

question: do the unicode tables cover gbk and big 5 well?

assuming this, how about making a set of tfm,enc,map files that match 
the unicode positions (volunteers ...)

we can extend the utf handler with a kind of plugin mechanism:

\unprotect

\def\utfunihashglyph#1%
  {\@EA\doutfunihashglyph\@EA{\number\utfdiv{#1}}{#1}} % only div once

\def\doutfunihashglyph#1#2% div raw
  {\csname
     \ifnum#2<\utf@i
       \strippedcsname\unicodeasciicharacter
     \else\ifcsname\@@unicommand#1\endcsname
       \@@unicommand#1%
     \else\ifcsname\@@univector#1\endcsname
       \@@univector#1%
     \else
       \strippedcsname\unicodeunknowncharacter
     \fi\fi\fi
     \@EA\endcsname\@EA{\number\utfmod{#2}}} % only mod once

\def\unicodeunknowncharacter#1%
  {\unknownchar}

\let\utfunihash\utfunihashglyph

\def\@@unicommand{@@unicommand}

\def\defineutfcommand #1 #2%
  {\setvalue{\@@unicommand#1}##1{#2{#1}{##1}}}

so we can define pluig in handlers for e.g. chinese

\defineutfcommand 81 {\uchar}

(bombs due to missing fonts, so for testing)

\def\NotYet#1#2{[#1 #2]}

\defineutfcommand 81 {\NotYet}

(next comes adapting the chinese files; i can imagine that we redo the 
big5 and gbk definitions so that they remap to ut8 as common encoding)

so .. the question is ... who is going to make the tfm/enc/map files

Hans

Re: Chinese

[Tobias Burnus]

Hi,

Hans Hagen wrote:
> chinese is not yet defined in utf so if you want that, we need to do it
We probably should.

> question: do the unicode tables cover gbk and big 5 well?
There exists a one-to-one correspondence between GBK and Unicode [1], 
for Big5 there are 7 characters which cannot be mapped one-to-one (see 
comment at top of [2]); thee of which appear twice in Big5 but only once 
in Unicode, two are not in unicode and there are two mapping problems.
In practive one can thus say: Both GBK and Big5 can be mapped to Unicode.

> assuming this, how about making a set of tfm,enc,map files that match 
> the unicode positions (volunteers ...)
If I get the time, I will play around with the four fonts mentioned on 
http://wiki.contextgarden.net/Chinese
Adam mentioned 
http://www.physik.fu-berlin.de/~tburnus/linlibertine/LibertineUnicode.zip, 
which contains LibertineInConTeXt.txt, which describes a possible way to 
do so.
But I wouldn't mind if someone who has more experience in playing around 
with .enc files would do the job ;)

Tobias

Re: Chinese

[Richard Gabriel]

[-- Attachment #1.1: Type: text/plain, Size: 3228 bytes --]

Hello Hans,

to be honest: I don't speak Chinese and don't know much about it.
A few days ago, I was told that we'll let translate some of our documents (XML) into Chinese and Japanese and I 'll have to typeset them. 
So I started playing with Chinese in ConTeXt. I've reported the results which other users (e.g. Tobias) have also noticed. 
In fact, all the sample Simplified Chinese documents I've tested it on were easily convertible to CP936 (GBK) and could be typeset. This doesn't mean that you shall not extend the Unicode support, I only think I will not hardly require it... :-)

But yet another question: What about Japanese? I've made only small research so far, but unlike Chinese, there's almost no information about Japanese in TeX. How much of work would be to adjust the current "chinese" ConTeXt module for Japanese? What would you need for it?
[Of course, meanwhile I'll investigate some other ways of typesetting Japanese...]

Thanks,
Richard



  _____  

From: Hans Hagen [mailto:pragma@wxs.nl]
To: mailing list for ConTeXt users [mailto:ntg-context@ntg.nl]
Sent: Mon, 12 Dec 2005 16:53:51 +0100
Subject: Re: [NTG-context] Chinese

Richard Gabriel wrote:

> Hi guys,
>
> I can confirm that the UTF-8 input doesn't work for me too.
> If I convert the file info GBK (CP936), it works fine [I suggest to 
> use the 'iconv' utility for the conversion :-)].
>
> I tested the UTF-8 output the followin ways:
>
> 1)
> \enableregime[utf]
> \usemodule[chinese]
>

chinese is not yet defined in utf so if you want that, we need to do it

now, since the chinese remapping stuff is rather complex, the best 
method is to consider a dedicated mechanism

question: do the unicode tables cover gbk and big 5 well?

assuming this, how about making a set of tfm,enc,map files that match 
the unicode positions (volunteers ...)

we can extend the utf handler with a kind of plugin mechanism:

\unprotect

\def\utfunihashglyph#1%
  {\@EA\doutfunihashglyph\@EA{\number\utfdiv{#1}}{#1}} % only div once

\def\doutfunihashglyph#1#2% div raw
  {\csname
     \ifnum#2<\utf@i
       \strippedcsname\unicodeasciicharacter
     \else\ifcsname\@@unicommand#1\endcsname
       \@@unicommand#1%
     \else\ifcsname\@@univector#1\endcsname
       \@@univector#1%
     \else
       \strippedcsname\unicodeunknowncharacter
     \fi\fi\fi
     \@EA\endcsname\@EA{\number\utfmod{#2}}} % only mod once

\def\unicodeunknowncharacter#1%
  {\unknownchar}

\let\utfunihash\utfunihashglyph

\def\@@unicommand{@@unicommand}

\def\defineutfcommand #1 #2%
  {\setvalue{\@@unicommand#1}##1{#2{#1}{##1}}}

so we can define pluig in handlers for e.g. chinese

\defineutfcommand 81 {\uchar}

(bombs due to missing fonts, so for testing)

\def\NotYet#1#2{[#1 #2]}

\defineutfcommand 81 {\NotYet}

(next comes adapting the chinese files; i can imagine that we redo the 
big5 and gbk definitions so that they remap to ut8 as common encoding)

so .. the question is ... who is going to make the tfm/enc/map files

Hans

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
  

[-- Attachment #1.2: Type: text/html, Size: 4029 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: Chinese

[Hans Hagen]

Richard Gabriel wrote:

> Hello Hans,
>
> to be honest: I don't speak Chinese and don't know much about it.
> A few days ago, I was told that we'll let translate some of our 
> documents (XML) into Chinese and Japanese and I 'll have to typeset them.
> So I started playing with Chinese in ConTeXt. I've reported the 
> results which other users (e.g. Tobias) have also noticed.
> In fact, all the sample Simplified Chinese documents I've tested it on 
> were easily convertible to CP936 (GBK) and could be typeset. This 
> doesn't mean that you shall not extend the Unicode support, I only 
> think I will not hardly require it... :-)
>
> But yet another question: What about Japanese? I've made only small 
> research so far, but unlike Chinese, there's almost no information 
> about Japanese in TeX. How much of work would be to adjust the current 
> "chinese" ConTeXt module for Japanese? What would you need for it?
> [Of course, meanwhile I'll investigate some other ways of typesetting 
> Japanese...]

it's all a matter of fonts and specs; handling those languages is not 
that complex

the main complication is in the encodings (related to the input) and 
utf8 makes sense as common encoding; context (newtexexec) has provisions 
for runtime recoding

what do the chinese users think of it ...

Hans

Re: Chinese

[Xiao Jianfeng]

Richard Gabriel wrote:

> Hello Hans,
>
> to be honest: I don't speak Chinese and don't know much about it.
> A few days ago, I was told that we'll let translate some of our 
> documents (XML) into Chinese and Japanese and I 'll have to typeset them.
> So I started playing with Chinese in ConTeXt. I've reported the 
> results which other users (e.g. Tobias) have also noticed.
> In fact, all the sample Simplified Chinese documents I've tested it on 
> were easily convertible to CP936 (GBK) and could be typeset. This 
> doesn't mean that you shall not extend the Unicode support, I only 
> think I will not hardly require it... :-)
>
> But yet another question: What about Japanese? I've made only small 
> research so far, but unlike Chinese, there's almost no information 
> about Japanese in TeX. How much of work would be to adjust the current 
> "chinese" ConTeXt module for Japanese? What would you need for it?
> [Of course, meanwhile I'll investigate some other ways of typesetting 
> Japanese...]
>
> Thanks,
> Richard
>
 As far as I know, LaTeX coupled with CJK package can process Chinese, 
Japanese, Korea.

 Regards,

xiaojf

>
>
>     ------------------------------------------------------------------------
>     *From:* Hans Hagen [mailto:pragma@wxs.nl]
>     *To:* mailing list for ConTeXt users [mailto:ntg-context@ntg.nl]
>     *Sent:* Mon, 12 Dec 2005 16:53:51 +0100
>     *Subject:* Re: [NTG-context] Chinese
>
>     Richard Gabriel wrote:
>
>     > Hi guys,
>     >
>     > I can confirm that the UTF-8 input doesn't work for me too.
>     > If I convert the file info GBK (CP936), it works fine [I suggest to
>     > use the 'iconv' utility for the conversion :-)].
>     >
>     > I tested the UTF-8 output the followin ways:
>     >
>     > 1)
>     > \enableregime[utf]
>     > \usemodule[chinese]
>     >
>
>     chinese is not yet defined in utf so if you want that, we need to
>     do it
>
>     now, since the chinese remapping stuff is rather complex, the best
>     method is to consider a dedicated mechanism
>
>     question: do the unicode tables cover gbk and big 5 well?
>
>     assuming this, how about making a set of tfm,enc,map files that match
>     the unicode positions (volunteers ...)
>
>     we can extend the utf handler with a kind of plugin mechanism:
>
>     \unprotect
>
>     \def\utfunihashglyph#1%
>     {\@EA\doutfunihashglyph\@EA{\number\utfdiv{#1}}{#1}} % only div once
>
>     \def\doutfunihashglyph#1#2% div raw
>     {\csname
>     \ifnum#2<\utf@i <mailto:utf@i>
>     \strippedcsname\unicodeasciicharacter
>     \else\ifcsname\@@unicommand#1\endcsname
>     \@@unicommand#1%
>     \else\ifcsname\@@univector#1\endcsname
>     \@@univector#1%
>     \else
>     \strippedcsname\unicodeunknowncharacter
>     \fi\fi\fi
>     \@EA\endcsname\@EA{\number\utfmod{#2}}} % only mod once
>
>     \def\unicodeunknowncharacter#1%
>     {\unknownchar}
>
>     \let\utfunihash\utfunihashglyph
>
>     \def\@@unicommand{@@unicommand}
>
>     \def\defineutfcommand #1 #2%
>     {\setvalue{\@@unicommand#1}##1{#2{#1}{##1}}}
>
>     so we can define pluig in handlers for e.g. chinese
>
>     \defineutfcommand 81 {\uchar}
>
>     (bombs due to missing fonts, so for testing)
>
>     \def\NotYet#1#2{[#1 #2]}
>
>     \defineutfcommand 81 {\NotYet}
>
>     (next comes adapting the chinese files; i can imagine that we redo
>     the
>     big5 and gbk definitions so that they remap to ut8 as common encoding)
>
>     so .. the question is ... who is going to make the tfm/enc/map files
>
>     Hans
>
>     _______________________________________________
>     ntg-context mailing list
>     ntg-context@ntg.nl <mailto:ntg-context@ntg.nl>
>     http://www.ntg.nl/mailman/listinfo/ntg-context
>
>------------------------------------------------------------------------
>
>_______________________________________________
>ntg-context mailing list
>ntg-context@ntg.nl
>http://www.ntg.nl/mailman/listinfo/ntg-context
>  
>

Re: Chinese

[Hans Hagen]

Tobias Burnus wrote:

> Hi,
>
> Hans Hagen wrote:
>
>> chinese is not yet defined in utf so if you want that, we need to do it
>
> We probably should.
>
>> question: do the unicode tables cover gbk and big 5 well?
>
> There exists a one-to-one correspondence between GBK and Unicode [1], 
> for Big5 there are 7 characters which cannot be mapped one-to-one (see 
> comment at top of [2]); thee of which appear twice in Big5 but only 
> once in Unicode, two are not in unicode and there are two mapping 
> problems.
> In practive one can thus say: Both GBK and Big5 can be mapped to Unicode.

so, if we can make things utf deep down and remap gbk and big 5 to utf, 
we can do with one set of fonts, metrics etc

i got chinese working in utf now, but need an enco table for teh special 
cases (see enco-chi); when someone made me that table, i can upload an 
alpha

Hans

Re: Chinese

[Duncan Hothersall]

Hans wrote:

> chinese is not yet defined in utf so if you want that, we need to do it
...
> assuming this, how about making a set of tfm,enc,map files that match 
> the unicode positions (volunteers ...)

I'm very willing to help, especially if there is some drudge work
involved in constructing the files. I don't know enough (yet) about the
logic of it all to help with setting up the system, but if someone can
supply skeleton files and/or a method for constructing the necessary
files, I'm happy to do any leg-work.

Duncan

Re: Chinese

[Duncan Hothersall]

Tobias Burnus asks:

> What would be needed to get UTF-8 input running with Chinese?

If there is a recipe, I would like to help cook it. Getting UTF-8 input
running with Chinese would be a godsend to me too.

Duncan

Re: chinese

[Hans Hagen]

At 01:42 PM 5/26/2002 -0500, Mr. Lei Wang wrote:
> > how did you produce the pdf file (using mptopdf or texexec --fig=c --pdf
> > file.1 ?)
>
>The pdf file produced by above two methods is inserted correctly.
>
>My testing pdf file is converted by epstopdf. Yesterday I try the newest
>version, but the output pdf file can not insert correctly, either.

ok, then forget about epstopdf for metapost, the tex methods 
(texexec/mptopdf) are better for mp anyway and also provide you features 
like transparency (see latest metafun manual)

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re: chinese

[Mr. Lei Wang]

> how did you produce the pdf file (using mptopdf or texexec --fig=c --pdf 
> file.1 ?)

The pdf file produced by above two methods is inserted correctly.

My testing pdf file is converted by epstopdf. Yesterday I try the newest
version, but the output pdf file can not insert correctly, either.

Other test show that the MP files used as overlay also work although
it seems not correctly when use the presentation modules. I try to 
test more functions.

Wang

Re: chinese

[Hans Hagen]

At 12:55 PM 5/25/2002 -0500, Mr. Lei Wang wrote:
> > \setupoutput[dvipdfm]
>
>It works for most plain documents.
>
> > should work; as far as i know most features work but i'm not sure about mp
> > inclusion (one could always make independent pdf's first); if features are
> > missing but possible we can add them of course
>
>When I test place figure in documents, the MP inclusion seems work.
>I use:
>   \startuseMPgraphic{test}
>   ... some mp code here
>   \stopuseMPgraphic
>
>\starttext
>
>    \placefigure[here][fig1]{Test MP}{\useMPgraphic{test}}
>
>    \placefigure[here][fig2]{Test PDF}{\externalfigure[test2.pdf]}
>
>\stoptext
>
>here the test2.pdf is a pdf figure convert from the same mp code.
>the first figure is OK. but the second can not placed because tex
>could not determine its dimension correctly. I try to use
>" ebb test2.pdf " get the boundingbox information of test2.pdf
>and stored it in test2.bb. this usually works in latex. But texexec
>seems not read the test2.bb file to get the dimension.

how did you produce the pdf file (using mptopdf or texexec --fig=c --pdf 
file.1 ?)

(actually, there is a module that also treats the bb file, but this is 
related to a new fig labeling mechanism, but this is not yet in the 
distribution)

Hans

-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re: chinese

[Hans Hagen]

At 02:42 AM 5/18/2002 +0200, Jens-Uwe Morawski wrote:

>yesterday i found the mchinese manual on the server. Previously
>i though that the up-to-date-7 is the only documentation about
>chinese in ConTeXT.
>
>The current version has some unfinished sections. Is there any plan
>that this will change soon (in some weeks)?
>Especially i would like to know what program is a good choice on Linux
>and Windows to edit chinese TeX files. Emacs-MuLE?
>What encoding should i use to save TeX files, UTF-8?
>Any other important hints?

Last week

   "Lei Wang" <wanglei@sbcglobal.net>

announced to pick up the chinese thread; he can best advice on editing 
(there are some tools for windows), encoding etc.

[the missing will certainly be filled in, but i depend on Lei Wangs 
expertise]

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

chinese

[Jens-Uwe Morawski]

Hullo,

yesterday i found the mchinese manual on the server. Previously
i though that the up-to-date-7 is the only documentation about
chinese in ConTeXT.

The current version has some unfinished sections. Is there any plan
that this will change soon (in some weeks)?
Especially i would like to know what program is a good choice on Linux
and Windows to edit chinese TeX files. Emacs-MuLE?
What encoding should i use to save TeX files, UTF-8?
Any other important hints?

Many thanks. Best,
  Jens