Alan BRASLAU wrote:

There appears to be a bug in mkiv with greek letters (and other math symbols?) within ppchtex. I am using the latest conTeXt minimals: (This is LuaTeX, Version snapshot-0.35.0 ConTeXt ver: 2009.01.18 14:39 MKIV fmt: 2009.2.24 int: english/english)

(Almost) minimal example (and attached pdf results).

\enableregime[utf] \usemodule[chemic]

\starttext \startTEXpage \startchemical[width=fit,height=fit] \chemical[ONE,Z0,MOV1,SB5,Z0][C_{\alpha},C_α] \stopchemical \stopTEXpage \stoptext

(Under mkiv, the \alpha becomes an ff ligature)

- the ff is because you use an old version - the nullfont message is because we have only one fam now, this fixes it (i've added it to ppchtex) \ifx\Umathchar\undefined \else % for the moment we nil them, soon we will have a proper % way to deal with this \let\setsubscripts \relax \let\resetsubscripts\relax \fi the \alpha shows up, the α not (not sure why) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

I confirm that this now works using the current --context=alpha

...

\enableregime[utf]

mkiv is utf by default -)

(But is still necessary to remain compatible with mkii)

...

the \alpha shows up, the α not (not sure why)

you need the mathematical alpha

\startTEXpage \startchemical[width=fit,height=fit] \chemical[ONE,Z0,MOV1,SB5,Z0][C_{\alpha},C_{\utfchar{"1D6FC}}] \stopchemical \stopTEXpage

OK, I see that TeX input is to be retained... However, note that $K_α$ works, so there must be some confusion in interpreting unicode characters in the macros.

On Wed, Feb 25, 2009 at 09:23, Hans Hagen wrote:

Alan BRASLAU wrote:

...

I confirm that this now works using the current --context=alpha

...

...

\enableregime[utf]

mkiv is utf by default -)

(But is still necessary to remain compatible with mkii)

...

...

the \alpha shows up, the α not (not sure why)

you need the mathematical alpha

\startTEXpage        \startchemical[width=fit,height=fit]

 \chemical[ONE,Z0,MOV1,SB5,Z0][C_{\alpha},C_{\utfchar{"1D6FC}}]        \stopchemical \stopTEXpage

OK, I see that TeX input is to be retained...

However, note that $K_α$ works, so there must be some confusion in interpreting unicode characters in the macros.

ppchtex uses an upright and there is no alpha in the base lm font

if you use

\usetypescript[cambria]\setupbodyfont[cambria]

you will get the right alpha

Hans, maybe italic (mathematical) alpha should be a fallback for normal alpha in LM. Personally, I have always been satisfied with italic alpha for labeling C atoms or alpha chains of proteins. So it should also be OK (not to say preferrable) to use "mathematical greek" inside chemistry formulae. Mojca

Yue Wang wrote:

Oh, Hans, another bug report, pls test this (come from my thesis):

\usetypescript[palatino] \setupbodyfont[palatino,rm] \starttext

\placeformula\startformula P_{(i,j)}=\sum_{n=1}^{n_s} P_{{\rm straight},n} \sum_{n=1}^{n_b} P_{{\rm bend},n} \stopformula

\placeformula\startformula {{\rm d} {\bf y}\over {\rm d} t} = f(t,{\bf y}) \quad {\bf y}(0)={\bf k} \stopformula \stoptext

i have no clue what you expect .. the bold y? if so ... we need to add the bold definition to the vf spec mathematics.make_font ( "px-math", { { name = "texgyrepagella-regular", features = "virtualmath", main = true }, { name = "pxr", vector = "traditional-mr" } , { name = "pxmi", vector = "traditional-mi", skewchar=0x7F }, { name = "pxsy", vector = "traditional-sy", skewchar=0x30, parameters = true } , { name = "pxex", vector = "traditional-ex", extension = true } , { name = "pxsya", vector = "traditional-ma" }, { name = "pxsyb", vector = "traditional-mb" }, } ) (feel free to figure out what font -) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Otared Kavian wrote:

On 1 mars 09, at 19:53, Hans Hagen wrote:

...

Yue Wang wrote:

...

Oh, Hans, another bug report, pls test this (come from my thesis): \usetypescript[palatino] \setupbodyfont[palatino,rm] \starttext \placeformula\startformula P_{(i,j)}=\sum_{n=1}^{n_s} P_{{\rm straight},n} \sum_{n=1}^{n_b} P_{{\rm bend},n} \stopformula \placeformula\startformula {{\rm d} {\bf y}\over {\rm d} t} = f(t,{\bf y}) \quad {\bf y}(0)={\bf k} \stopformula \stoptext

i have no clue what you expect .. the bold y? if so ... we need to add the bold definition to the vf spec

Hi Hans,

I guess what Yue Wang wants to say is that in mkiv the summation sign \sum has a small size, analogous to the in-line math $\sum$, while in mkii the ersult is as expected.

ok, thanks Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On Mon, Mar 2, 2009 at 11:57 AM, Yue Wang wrote:

yes, that's what the second equation points out.

s/second/first

On Mon, Mar 2, 2009 at 3:02 AM, Otared Kavian wrote:

...

On 1 mars 09, at 19:53, Hans Hagen wrote:

...

Yue Wang wrote:

...

Oh, Hans, another bug report, pls test this (come from my thesis): \usetypescript[palatino] \setupbodyfont[palatino,rm] \starttext \placeformula\startformula P_{(i,j)}=\sum_{n=1}^{n_s} P_{{\rm straight},n} \sum_{n=1}^{n_b} P_{{\rm bend},n} \stopformula \placeformula\startformula {{\rm d} {\bf y}\over {\rm d} t} = f(t,{\bf y}) \quad {\bf y}(0)={\bf k} \stopformula \stoptext

i have no clue what you expect .. the bold y? if so ... we need to add the bold definition to the vf spec

Hi Hans,

I guess what Yue Wang wants to say is that in mkiv the summation sign \sum has a small size, analogous to the in-line math $\sum$, while in mkii the ersult is as expected.

Best regards: OK

___________________________________________________________________________________ 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 ___________________________________________________________________________________

${\bf y}$ still gives me roman regular y. On Mon, Mar 2, 2009 at 2:53 AM, Hans Hagen wrote:

Yue Wang wrote:

...

Oh, Hans, another bug report, pls test this (come from my thesis):

\usetypescript[palatino] \setupbodyfont[palatino,rm] \starttext

\placeformula\startformula P_{(i,j)}=\sum_{n=1}^{n_s} P_{{\rm straight},n} \sum_{n=1}^{n_b} P_{{\rm bend},n} \stopformula

\placeformula\startformula {{\rm d} {\bf y}\over {\rm d} t} = f(t,{\bf y}) \quad {\bf y}(0)={\bf k} \stopformula \stoptext

i have no clue what you expect .. the bold y? if so ... we need to add the bold definition to the vf spec

mathematics.make_font ( "px-math", {    { name = "texgyrepagella-regular", features = "virtualmath", main = true },    { name = "pxr", vector = "traditional-mr" } ,    { name = "pxmi", vector = "traditional-mi", skewchar=0x7F },    { name = "pxsy", vector = "traditional-sy", skewchar=0x30, parameters = true } ,    { name = "pxex", vector = "traditional-ex", extension = true } ,    { name = "pxsya", vector = "traditional-ma" },    { name = "pxsyb", vector = "traditional-mb" }, } )

(feel free to figure out what font -)

-----------------------------------------------------------------                                          Hans Hagen | PRAGMA ADE              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com                                             | www.pragma-pod.nl ----------------------------------------------------------------- ___________________________________________________________________________________ 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 ___________________________________________________________________________________

Yue Wang wrote:

Hi, Hans:

Are HZ features still working? I test the beta with one of my documents, and it gives very bad line break:(

it should work ok ... what testfile do you use? ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

HZ feature is still not working in the latest beta. (Wolfgang's example is a good test for that) 2009/3/2 Wolfgang Schuster :

Am 01.03.2009 um 18:19 schrieb Hans Hagen:

...

Yue Wang wrote:

...

Hi, Hans: Are HZ features still working? I test the beta with one of my documents, and it gives very bad line break:(

it should work ok ... what testfile do you use?

He's is right, here is a example.

\definefontfeature[default][default][script=latn,mode=node,expansion=quality,protrusion=quality]

\usetypescript[palatino] \setupbodyfont[palatino]

\mainlanguage[de]

\starttext

Ein König von Baßrah besaß große Reichtümer. Seine Untertanen liebten ihn, aber er hatte keine Kinder, und das betrübte ihn über die Maßen. Indes veranlaßte er alle heiligen Männer in seinen Staaten durch namhafte Geschenke, den Himmel für ihn um einen Sohn zu bitten, und ihre Gebete waren nicht erfolglos: die Königin wurde schwanger und genas glücklich eines Sohnes. welcher den Namen Zeyn Alasnam, d\,h~Zierde der Bildsäulen, erhielt.

Der König ließ alle Sterndeuter seines Reiches zusammenrufen und befahl ihnen, dem Kind das Horoskop zu stellen. Sie entdeckten durch ihre Beobachtungen, daß er lange leben und viel Mut besitzen würde, daß er dieses Mutes aber auch bedürfe, um das vielfache Unglück, das ihn bedrohe, mannhaft zu ertragen. Der König erschrak nicht über diese Weissagung, »Wenn mein Sohn Mut hat«, sagte er, »so ist er nicht zu beklagen. Es ist gut, wenn die Prinzen manchmal in ein Unglück kommen; Widerwärtigkeiten läutern ihre Tugend, sie lernen dadurch nur um so besser regieren.«

\stoptext

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 ___________________________________________________________________________________

Yanrui Li wrote:

2009/2/25 Hans Hagen :

...

Hi,

As prelude to LuaTeX 0.40 there is now a beta 0.35. I uploaded a context beta that matches this version. The most important move is that we now have a new math subsystem. (Specially for Mojca: iwona seems to work ok). Apart from bringin unicode math this also gives a better performance. (Some info about what is involved can be found in mk.pdf on the website).

There might be ommisions so when you run into one, just let us know.

Hi,

Maybe there are some bugs in scrp-ini.lua and scrp-cjk.lua as follows:

1. In scrp-ini.lua, some flags of punctuations in the definition of "hash" are replaced by "chinese" flags, for example:

local hash = { ... ... [0xFF0C] = "full_width_close", -- ， ... ... } ... ... for i=0x0FF00,0x0FFEF do hash[i] = "chinese" end ... ...

2. In scrp-cjk.lua, it seems that "insert_node_before" in some break & shrink & stretch functions should be "insert_node_after", for example:

local function nobreak_stretch(head,current) insert_node_before(head,current,make_penalty_node(10000)) insert_node_before(head,current,make_glue_node(0,inter_char_stretch,0)) end

we only insert nodes before, so in that case you need to look at another combination; so, like [insert] is triggered only once, by the table entry [class a] = { class_b = ... }

In addition, I found Chinese punctuations compression in this beta. Will these features be provided in future beta?

maybe, once we have decided on a proper reference font ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Yanrui Li wrote:

2009/3/2 Hans Hagen :

...

Yanrui Li wrote:

...

2009/2/25 Hans Hagen :

...

Hi,

As prelude to LuaTeX 0.40 there is now a beta 0.35. I uploaded a context beta that matches this version. The most important move is that we now have a new math subsystem. (Specially for Mojca: iwona seems to work ok). Apart from bringin unicode math this also gives a better performance. (Some info about what is involved can be found in mk.pdf on the website).

There might be ommisions so when you run into one, just let us know.

Hi,

Maybe there are some bugs in scrp-ini.lua and scrp-cjk.lua as follows:

1. In scrp-ini.lua, some flags of punctuations in the definition of "hash" are replaced by "chinese" flags, for example:

local hash = { ... ... [0xFF0C] = "full_width_close", -- ， ... ... } ... ... for i=0x0FF00,0x0FFEF do hash[i] = "chinese" end ... ...

2. In scrp-cjk.lua, it seems that "insert_node_before" in some break & shrink & stretch functions should be "insert_node_after", for example:

local function nobreak_stretch(head,current) insert_node_before(head,current,make_penalty_node(10000)) insert_node_before(head,current,make_glue_node(0,inter_char_stretch,0)) end we only insert nodes before, so in that case you need to look at another combination; so, like

[insert]

is triggered only once, by the table entry

[class a] = { class_b = ... }

Thanks for your explanation, I see.

There are some Chinese punctuations, such as “，" (fullwidth comma), "！" (fullwidth exclamation mark) and so on, which are considered to be "chinese" but not "full_width_close" by scrp-cjk.lua. Is this deliberately doing?

we have different vectors for chinese and korean and each of them can be optimized, of there can be several for each script keep in mind that when korean uses chinese, it does not use the chinese rules Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Dohyun Kim wrote:

2009/3/2 Hans Hagen :

...

Yanrui Li wrote:

...

There are some Chinese punctuations, such as “，" (fullwidth comma), "！" (fullwidth exclamation mark) and so on, which are considered to be "chinese" but not "full_width_close" by scrp-cjk.lua. Is this deliberately doing? we have different vectors for chinese and korean and each of them can be optimized, of there can be several for each script

keep in mind that when korean uses chinese, it does not use the chinese rules

Those Chinese punctuations we Koreans seldom use. Nor we normally use characters from U+FF00 .. U+FFFF area. So it's OK to delete this line in scip-ini.lua :

for i=0x0FF00,0x0FFEF do hash[i] = "chinese" end

as requested by Chinese people.

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. ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Dohyun Kim wrote:

2009년 3월 2일 (월) 오후 7:02, Hans Hagen 님의 말:

...

...

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.

Dohyun Kim wrote: 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".

i do it for all ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------