Khaled Hosny wrote:
> On Sat, Aug 23, 2008 at 12:46:47AM +0300, Khaled Hosny wrote:
>> It seems that there is a bug in converters.alphabetic function,
>> converters.alphabetic(0,"arabic") returns the western 0 (no matter what
>> is the selected language) while converters.alphabetic(1,"arabic") gives
>> the Arabic 0 not 1 and so one i.e. it looks like as if it starts
>> counting from zero.
> 
> I finally got myself to understand some lua code.
> 
> I think the problem is that lua tables start counting from 1 not 0,
> getting the value of key 0 from code table will give nil while 1 will
> give the value of 0 (first key), so the solution would be incrementing n
> by 1 in:
> 
> local function do_alphabetic(n,max,chr)
>     n = n + 1 -- to get the correct key
>     if n > max then
>         do_alphabetic(floor((n-1)/max),max,chr)
>         n = (n-1)%max+1
>     end
>     characters.flush(chr(n))
> end
> 
> This does work for the case of Arabic, but I don't know about others
> (especially greek and slovenian which look different)

we cannot change that function without breaking other things

there are several ways to convert, one is using the languages.counters 
table and i don't know if the arabic entries in it are right (i just 
found out that the greek vector is uppercase while it should be 
lowercase but i'll make a fix for that)


 >rgrep arabicn *.tex

core-con.tex 671: \defineconversion [arabicnumerals]   [\arabicnumerals]
core-con.tex 672: \defineconversion [persiannumerals]  [\arabicnumerals]
 >rgrep arabicn *.mkiv

core-con.mkiv 20: \def\abjadnumerals 
#1{\ctxlua{converters.arabicnumerals(\number#1)}}
core-con.mkiv 21: \def\abjadnodotnumerals 
#1{\ctxlua{converters.arabicnodotnumerals(\number#1)}}
core-con.mkiv 22: \def\abjadnaivenumerals 
#1{\ctxlua{converters.arabicnaivenumerals(\number#1)}}
core-con.mkiv 87: \def\arabicnumerals 
#1{\ctxlua{converters.alphabetic(\number#1,"arabic")}}
core-con.mkiv 99: \defineconversion [arabicnumerals]     [\arabicnumerals]
 >

the abjad number converters are definied differently (based on specs by 
idris)

so, if the 0/1 offset is a problem then we need to fix the tables, not 
the function (unless arabic follows a different logic, as chinese does)

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

Reply via email to