Re: frontmatter

Re: frontmatter

[wwl]

> > - a space-char between 'doublesided' and ']' removes the last
> blank 
> > page (strange).
> 
> This is normal: 'doublesided' is not equal to 'doublesided '.
> And 'doublesided' requires certainly an even number of pages.

Ohh! But a leading space has no effekt.
What is the exact syntax for parameters?

Wolfgang

Re: frontmatter

[wwl]

> Hi Wolfgang,
> 
> I tried your code. Indeed there is no blank page after the
> "Schmutztitel".

But a blank page before!

> So you need to add to the \startstandardmakeup[page=yes]. -

No that doesn't help.
And it shouldn't be necessary. Right?

> Something 
> fuzzy is at hand with grid=yes.
> If you comment this line then the output is as expected.

I know. I wrote that. I found 3 positions which, commenting this 
lines, correct the problem.

But I don't understand WHY this helps and why the example doesn't 
works.

> 
> 
> Willi
> 
> 
> wwl@musensturm.de wrote:
> > Hallo!
> >
> > I am trying to use 'standardmakeup' to produce
> 'Schmutztitel'-page
> > with a following blank page. I think this is what 
> > \start\stopstandardmakeup is for (in doublesided environments).
> >
> > But the example bellow has first a blank page and then 
> > 'Schmutztitel'.
> >
> > There is a fourth blank page too.
> >
> > -------------------------
> > \setuppagenumbering	[alternative=doublesided]
> > \setuplayout	[
> >                     footer=.04\paperheight,     %1
> >                     grid=yes,                   %2
> >                     marking=on,
> >                     location=middle,
> >                     width=middle,
> >                     height=middle]
> > \starttext
> > \startfrontmatter                               %3
> > \startstandardmakeup
> > Schmutztitel
> > \stopstandardmakeup
> > \stopfrontmatter                                %3
> > bla
> > \stoptext
> > -------------------------
> >
> > My experiments:
> >
> > - a space-char between 'doublesided' and ']' removes the last
> blank 
> > page (strange).
> >
> > - uncommenting the lines in position 1,2,3 exclusivly results in
> the 
> > correct behaviour.
> >
> > I would like to understand what the problem is and why, for
> example, 
> > uncommenting frontmatter solves the problem.
> >
> > I thought frontmatter is the place to do title-things and so.
> >
> > Gr??e, Wolfgang

Re: Aleph queries

[Duncan Hothersall]

Idris wrote:

> I doubt it, but something along these lines should do it:
> 
> ======
> % tex=aleph output=dvipdfmx
> \pagedir TRT
> \bodydir TRT
> \pardir  TRT
> \textdir TRT
> \hoffset=0pt % bug
> 
> \starttext
> 
> \chapter{Cow}
> 
> \section{Dutch Cow}
> 
> \placefigure
> [middle]
> [fig:cow]
> {This is an example of a cow.}
> {\externalfigure[cow][width=1.5in]}
> 
> \section{Another Dutch Cow}
> 
> \placefigure
> [middle]
> [fig:cow]
> {This is an example of a cow.}
> {\externalfigure[cow][width=1.5in]}
> 
> \stoptext
> 
> ======
> 
> Hmm, seems to work here; maybe Duncan did not use \bodydir TRT?

I agree the above works, but when I use Arabic fonts and content it
doesn't seem to.

I have new tex and pdf files at:

http://www.capdm.com/public/context/figtest.tex
and
http://www.capdm.com/public/context/figtest.pdf

> Hans: How do we configure the "."=>"-" separator?

This I have worked out!

\setupcaption[figure][separator=-]

Doh. Thanks,

Duncan

Re: Aleph queries

[Hans Hagen]

Duncan Hothersall wrote:
>
> I agree the above works, but when I use Arabic fonts and content it
> doesn't seem to.
>
> I have new tex and pdf files at:
>
> http://www.capdm.com/public/context/figtest.tex
> and
> http://www.capdm.com/public/context/figtest.pdf
>   
hm, some weird interaction between opt's and directions and context reversing numbers ... i must look into it

what we need is a test doc with all relevant typo concepts that needs special treatment (either or not reversion) so that we can deal with all of them 

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

Re: Aleph queries

[Hans Hagen]

Duncan Hothersall wrote:
>
> I agree the above works, but when I use Arabic fonts and content it
> doesn't seem to.
>   
still puzzling

things like this (imo) conform that the ability to typeset in multiple directions not means that one claim to have a multilingual tex  

the problem is that there's always a mixture between this auto r/l stuff and explicit r/l stuff and one never knows (also depends on the otp's it seems) what happens: now we can have situations that the input parser reverse things that are already reversed and one never knows why/where (since those opt's have kind of unpredictable side effects (apart from bugs - i just ran out of mem again) 

figure [num1] . [num2] . [num3] 

should come out as 

 [num3] . [num2] . [num1] erugif

depending on when an otp decides that it should stop we get something else In any case, the num snippets needs to be otp'd in order to get proper arab, at the same time there's this *dir stuff, ...  

(omega was never made for such things, only simple docs with straightforward input, not too much macro package stuff involved) 

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

Re: Aleph queries

[Hans Hagen]

Duncan Hothersall wrote:
> Idris wrote:
>
>   
>> I doubt it, but something along these lines should do it:
>>
>> ======
>> % tex=aleph output=dvipdfmx
>> \pagedir TRT
>> \bodydir TRT
>> \pardir  TRT
>> \textdir TRT
>> \hoffset=0pt % bug
>>
>> \starttext
>>
>> \chapter{Cow}
>>
>> \section{Dutch Cow}
>>
>> \placefigure
>> [middle]
>> [fig:cow]
>> {This is an example of a cow.}
>> {\externalfigure[cow][width=1.5in]}
>>
>> \section{Another Dutch Cow}
>>
>> \placefigure
>> [middle]
>> [fig:cow]
>> {This is an example of a cow.}
>> {\externalfigure[cow][width=1.5in]}
>>
>> \stoptext
>>
>> ======
>>
>> Hmm, seems to work here; maybe Duncan did not use \bodydir TRT?
>>     
I tend to think that we should start with 

\def\ArabicUTF
  {\ArabicDirGlobal
   \usefiltersequence[UTFArabic]%
%    \reversesectionnumberstrue
   \switchtobodyfont[omarb]%
   \ArabicDirGlobal}

\ArabicUTF

\setuplabeltext[figure=استخلاØ~]

so, no reversing; the question is, why isn't this piece reflected in arab while ok in reflected english 

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

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

Re: Aleph queries

[Taco Hoekwater]

Hi,

Hans Hagen wrote:
> 
> figure [num1] . [num2] . [num3] 
> 
> should come out as 
> 
>  [num3] . [num2] . [num1] erugif

We discovered that the arabic contextual analyzation OTP assumes
that any sequence of [0-9.+-]+ is a single number and should be
typeset in TLT mode.

For figure numbers and version numbers etcetera this assumption
is wrong (they are multiple numbers concatenated together).

A trick (?) is to change the separator such that the number
parsing in the otp see separate numbers as well:

   \setupcaptions[separator={{.}}]


Cheers, Taco

Re: Aleph queries

[Hans Hagen]

Taco Hoekwater wrote:
> Hi,
>
> Hans Hagen wrote:
>   
>> figure [num1] . [num2] . [num3] 
>>
>> should come out as 
>>
>>  [num3] . [num2] . [num1] erugif
>>     
>
> We discovered that the arabic contextual analyzation OTP assumes
> that any sequence of [0-9.+-]+ is a single number and should be
> typeset in TLT mode.
>   
just curious: does this make sense? why is this?
> For figure numbers and version numbers etcetera this assumption
> is wrong (they are multiple numbers concatenated together).
>
> A trick (?) is to change the separator such that the number
> parsing in the otp see separate numbers as well:
>
>    \setupcaptions[separator={{.}}]
>   
or a bit more extensive:

\def\ArabicUTF
  {\ArabicDirGlobal
   \usefiltersequence[UTFArabic]%
   % not needed:   \reversesectionnumberstrue
   \switchtobodyfont[omarb]}

\setupheads   [separator={{.}}]
\setupcaptions[separator={{.}}]

 this still gives problems with refering to a graphic but for that we need more hackery 

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

Re: Aleph queries

[Hans Hagen]

Idris Samawi Hamid wrote:
> Hmm, I did not get the parent(s) to this email; was it off-list?
>   
yes, taco and i skyped a bit -)

anyhow, it looks like we need some low level support for this kind of 
things; playing with that now (not much time today)

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

Re: Aleph queries

[Idris Samawi Hamid]

Hmm, I did not get the parent(s) to this email; was it off-list?

Idris

On Fri, 23 Jun 2006 06:10:57 -0600, Duncan Hothersall <dh@capdm.com> wrote:

>>> A trick (?) is to change the separator such that the number
>>> parsing in the otp see separate numbers as well:
>>>
>>> \setupcaptions[separator={{.}}]
>>>
>> \setupheads [separator={{.}}]
>> \setupcaptions[separator={{.}}]
>>
>>  this still gives problems with refering to a graphic but for that we  
>> need more hackery
>
> Agreed, but this is a great step forward and explains the behaviour. It
> it true that in Arabic the digits making up a number should read from
> ltr while separated numbers forming a section or float reference should
> read rtl overall.
>
> So we are nearly there, just the cross-references to be dealt with,
> thank you all very much for this.

-- 
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Aleph queries

[Duncan Hothersall]

> \setupheads [separator={{.}}]
> \setupcaptions[separator={{.}}]
>
> this still gives problems with refering to a graphic but for that we
> need more hackery

Also, probably because it uses the same cross-referencing mechanism,
this leaves the section numbers in tables of contents the other way
around. So to match the setupheads, we need also:

\setuplist[section,subsection,...][separator={{.}}]


Unfortunately

\setupreferencing[separator={{.}}]

seems to just put an extra . before the figure number, but not reverse
it, resulting in:

'1.2- erugiF'


Duncan

Re: Aleph queries

[Duncan Hothersall]

>> A trick (?) is to change the separator such that the number
>> parsing in the otp see separate numbers as well:
>>
>> \setupcaptions[separator={{.}}]
>>
> \setupheads [separator={{.}}]
> \setupcaptions[separator={{.}}]
> 
>  this still gives problems with refering to a graphic but for that we need more hackery 

Agreed, but this is a great step forward and explains the behaviour. It
it true that in Arabic the digits making up a number should read from
ltr while separated numbers forming a section or float reference should
read rtl overall.

So we are nearly there, just the cross-references to be dealt with,
thank you all very much for this.

Duncan

Re: Aleph queries

[Idris Samawi Hamid]

On Wed, 21 Jun 2006 21:16:40 +0200, Hans Hagen <pragma@wxs.nl> wrote:

>>> so it's only the number that's wrong?
>>>
>>
>> That's right (though I have not tested it myself, relying on Duncan's
>> description)
>>
> hm, so now i need to install arab fonts, otps, etc in my current tree -)

Well, it's not that involved ;-)

http://wiki.contextgarden.net/Aleph_Guide#Installing

> i wonder how hard dit is to check it using reversed english (easier for 
> me) .. does Duncan has such a sample?

I doubt it, but something along these lines should do it:

======
% tex=aleph output=dvipdfmx
\pagedir TRT
\bodydir TRT
\pardir  TRT
\textdir TRT
\hoffset=0pt % bug

\starttext

\chapter{Cow}

\section{Dutch Cow}

\placefigure
[middle]
[fig:cow]
{This is an example of a cow.}
{\externalfigure[cow][width=1.5in]}

\section{Another Dutch Cow}

\placefigure
[middle]
[fig:cow]
{This is an example of a cow.}
{\externalfigure[cow][width=1.5in]}

\stoptext

======

Hmm, seems to work here; maybe Duncan did not use \bodydir TRT?

Hans: How do we configure the "."=>"-" separator?

Best
Idris

-- 
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

Re: Aleph queries

[Hans Hagen]

Idris Samawi Hamid wrote:
> On Wed, 21 Jun 2006 11:05:43 -0600, Hans Hagen <pragma@wxs.nl> wrote:
>
>   
>> Idris Samawi Hamid wrote:
>>     
>>> In Latin we write
>>>
>>> <Figure 1.2>
>>>
>>> in Arabic we want the equivalent of
>>>
>>> <2.1 erugiF>
>>>
>>> but Duncan seems to be getting
>>>
>>> <1.2 erugiF>
>>>
>>> even with global Arabic settings.
>>>
>>>       
>> so it's only the number that's wrong?
>>     
>
> That's right (though I have not tested it myself, relying on Duncan's  
> description)
>   
hm, so now i need to install arab fonts, otps, etc in my current tree -) 

i wonder how hard dit is to check it using reversed english (easier for me) .. does Duncan has such a sample? 

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

Re: Aleph queries

[Idris Samawi Hamid]

On Wed, 21 Jun 2006 11:05:43 -0600, Hans Hagen <pragma@wxs.nl> wrote:

> Idris Samawi Hamid wrote:
>> In Latin we write
>>
>> <Figure 1.2>
>>
>> in Arabic we want the equivalent of
>>
>> <2.1 erugiF>
>>
>> but Duncan seems to be getting
>>
>> <1.2 erugiF>
>>
>> even with global Arabic settings.
>>
> so it's only the number that's wrong?

That's right (though I have not tested it myself, relying on Duncan's  
description)

>> In addition Duncan would like to use a dash instead of a period:
>>
>> <2-1 erugiF>
>>
> that's configurable

I figured as much ;-)

Best
Idris

-- 
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Aleph queries

[Hans Hagen]

Idris Samawi Hamid wrote:
> On Wed, 21 Jun 2006 10:35:14 -0600, Hans Hagen <pragma@wxs.nl> wrote:
>
>   
>>>> \in{رسم بياني }[figref0102]
>>>>
>>>> to generate
>>>>
>>>> "رسم بياني 1-2"
>>>>
>>>> Any advice for that? (I had a search for other \reverse type commands
>>>> but no luck :-(
>>>>         
>>> Hans, can you do a \reverse macro for this?
>>>       
>> what do you mean with \reverse
>>
>> bla bla left to right bla bla \in {something arab right left} bla bla
>>
>> i assume that arab always should be reverse so one should either  
>> explicitly enable arab or is there something wrong with the \in macro
>>     
>
> In Latin we write
>
> <Figure 1.2>
>
> in Arabic we want the equivalent of
>
> <2.1 erugiF>
>
> but Duncan seems to be getting
>
> <1.2 erugiF>
>
> even with global Arabic settings.
>   
so it's only the number that's wrong?
> In addition Duncan would like to use a dash instead of a period:
>
> <2-1 erugiF>
>   
that's configurable

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

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

Re: Aleph queries

[Idris Samawi Hamid]

On Wed, 21 Jun 2006 10:35:14 -0600, Hans Hagen <pragma@wxs.nl> wrote:

>>> \in{رسم بياني }[figref0102]
>>>
>>> to generate
>>>
>>> "رسم بياني 1-2"
>>>
>>> Any advice for that? (I had a search for other \reverse type commands
>>> but no luck :-(
>>
>> Hans, can you do a \reverse macro for this?
> what do you mean with \reverse
>
> bla bla left to right bla bla \in {something arab right left} bla bla
>
> i assume that arab always should be reverse so one should either  
> explicitly enable arab or is there something wrong with the \in macro

In Latin we write

<Figure 1.2>

in Arabic we want the equivalent of

<2.1 erugiF>

but Duncan seems to be getting

<1.2 erugiF>

even with global Arabic settings.

In addition Duncan would like to use a dash instead of a period:

<2-1 erugiF>

Best
Idris

-- 
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: Aleph queries

[Idris Samawi Hamid]

On Wed, 21 Jun 2006 10:11:06 -0600, Duncan Hothersall <dh@capdm.com> wrote:

>> Well, I don't know which ligatures the proofreader liked/did not like  
>> so...
>
> Sorry, I realise that was a bit stupid of me... Thanks for your
> patience. :-)

I suspect it may be that the lam-yaa ligature appears to collide with the  
preceding yaa. My suggestion: instead of getting rid of the ligature do a  
global replace of

يلي

by

يـلي

and the like (placing the kashidah before the ligature). I could tell the  
otp to do this as well but that would take some testing etc. and I'm just  
swamped at the moment. Let me know what you would prefer and I'll get to  
it as soon as I can :-)

Best
Idris

-- 
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: Aleph queries

[Hans Hagen]

Idris Samawi Hamid wrote:
>>
>> and in Arabic I'd like to use
>>
>> \in{رسم بياني }[figref0102]
>>
>> to generate
>>
>> "رسم بياني 1-2"
>>
>> Any advice for that? (I had a search for other \reverse type commands
>> but no luck :-(
>
> Hans, can you do a \reverse macro for this?
what do you mean with \reverse

bla bla left to right bla bla \in {something arab right left} bla bla

i assume that arab always should be reverse so one should either explicitly enable arab or is there something wrong with the \in macro 


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

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

Re: Aleph queries

[Duncan Hothersall]

>> Am following this up via another route to try to better
>> understand what to do, but if you really did want a reminder about this
>> - here it is :-)
> 
> Well, I don't know which ligatures the proofreader liked/did not like so...

Sorry, I realise that was a bit stupid of me... Thanks for your
patience. :-)

Duncan

Re: Aleph queries

[Idris Samawi Hamid]

On Wed, 21 Jun 2006 09:37:50 -0600, Duncan Hothersall <dh@capdm.com> wrote:

> Idris Samawi Hamid (15/06/2006 17:28) said:
>
>> You could edit the cuni2oar otp (and recompile it) so that it
>> ignores the ligatures you don't like, or you could put a kashidah
>> between the two letters whose ligature you want to break. Better is to
>> define an "empty" kashidah so that you can manually break the ligature
>> without stretching the word. I'll look into this in the next few days
>> (busy right now) if you remind me-)
>
> Thanks very much for this, but unfortunately as an Arabic typesetting
> novice I can't quite follow it (the comments on the ligatures came from
> a proofreader).

> Am following this up via another route to try to better
> understand what to do, but if you really did want a reminder about this
> - here it is :-)

Well, I don't know which ligatures the proofreader liked/did not like so...

>> Add \reversesectionnumberstrue to your Arabic definition:
>
> Ah, great, perfect.
>
> Now I have a follow-up to that one: I also would like figure and table
> numbering to have the chapternumber in the right order and use - as a
> separator. In other words, in English I use
>
> \in{Figure}[figref0102]
>
> to generate
>
> "Figure 1.2"
>
> and in Arabic I'd like to use
>
> \in{رسم بياني }[figref0102]
>
> to generate
>
> "رسم بياني 1-2"
>
> Any advice for that? (I had a search for other \reverse type commands
> but no luck :-(

Hans, can you do a \reverse macro for this?

Best
Idris

-- 
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: Aleph queries

[Duncan Hothersall]

Idris Samawi Hamid (15/06/2006 17:28) said:

> You could edit the cuni2oar otp (and recompile it) so that it
> ignores the ligatures you don't like, or you could put a kashidah
> between the two letters whose ligature you want to break. Better is to
> define an "empty" kashidah so that you can manually break the ligature
> without stretching the word. I'll look into this in the next few days
> (busy right now) if you remind me-)

Thanks very much for this, but unfortunately as an Arabic typesetting
novice I can't quite follow it (the comments on the ligatures came from
a proofreader). Am following this up via another route to try to better
understand what to do, but if you really did want a reminder about this
- here it is :-)

> 
...
> Add \reversesectionnumberstrue to your Arabic definition:

Ah, great, perfect.

Now I have a follow-up to that one: I also would like figure and table
numbering to have the chapternumber in the right order and use - as a
separator. In other words, in English I use

\in{Figure}[figref0102]

to generate

"Figure 1.2"

and in Arabic I'd like to use

\in{رسم بياني }[figref0102]

to generate

"رسم بياني 1-2"

Any advice for that? (I had a search for other \reverse type commands
but no luck :-(

Many thanks again.

Duncan

PS. Apologies if the UTF-8 content there doesn't show up correctly.
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: Aleph queries

[Idris Samawi Hamid]

Hi Duncan,

On Thu, 15 Jun 2006 02:30:15 -0600, Duncan Hothersall <dh@capdm.com> wrote:

> Using the fantastic resources from Idris' messages on this list, and the
> Aleph page on the Wiki, I have managed to start producing Arabic PDF
> output directly from UTF-8 sources using Aleph and dvipdfmx. This is
> great, thanks so much.

Glad you liked it:-)

> I have just one or two queries and things I wasn't able to make work. I
> hope someone can help.
>
> My test file is here:
> http://www.capdm.com/public/context/omarab-queries1.tex
> And the output it generates is here:
> http://www.capdm.com/public/context/omarab-queries1.pdf
>
>
> First question - how do I get italic text? The first three paragraphs in
> the test are identical content, but the second has {\it ...} around it
> and the third has {\bf ...} around it. The third para comes out
> perfectly in bold, but the second para looks the same as the first. How
> can I get italics?

There is no italic font, only regular and bold, so \it just maps to the  
default regular font.

> Second question - that same first para contains 5 ligatures. They don't
> seem to match the rest of the font. Is this a set-up issue, or is it the
> way the font is designed? If it is a set-up issue, is there a way to fix  
> it?

Both :-) You could edit the cuni2oar otp (and recompile it) so that it  
ignores the ligatures you don't like, or you could put a kashidah between  
the two letters whose ligature you want to break. Better is to define an  
"empty" kashidah so that you can manually break the ligature without  
stretching the word. I'll look into this in the next few days (busy right  
now) if you remind me-)

> Third and final question - I inserted a section and two subsections to
> demonstrate that the numbering of subsections is left-to-right. How can
> I make it right-to-left? (Explanation: the PDF shows section "1", and
> then subsections "1-1" and "1-2"; reading the numbers from
> right-to-left, I need it to show as section "1" and then subsections
> "1-1" and "2-1". In the subsection the "1" should come first when
> reading rtl.)

Add \reversesectionnumberstrue to your Arabic definition:

\def\ArabicUTF{\ArabicDirGlobal\usefiltersequence[UTFArabic]
                 \reversesectionnumberstrue\switchtobodyfont[omarb]}

Ideally when one selects global RL this should happen automatically. This  
is being planned for the future :-)

Best
Idris

-- 
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Aleph queries

[Duncan Hothersall]

Hello all (especially Idris :-) )

Using the fantastic resources from Idris' messages on this list, and the
Aleph page on the Wiki, I have managed to start producing Arabic PDF
output directly from UTF-8 sources using Aleph and dvipdfmx. This is
great, thanks so much.

I have just one or two queries and things I wasn't able to make work. I
hope someone can help.

My test file is here:
http://www.capdm.com/public/context/omarab-queries1.tex
And the output it generates is here:
http://www.capdm.com/public/context/omarab-queries1.pdf


First question - how do I get italic text? The first three paragraphs in
the test are identical content, but the second has {\it ...} around it
and the third has {\bf ...} around it. The third para comes out
perfectly in bold, but the second para looks the same as the first. How
can I get italics?

Second question - that same first para contains 5 ligatures. They don't
seem to match the rest of the font. Is this a set-up issue, or is it the
way the font is designed? If it is a set-up issue, is there a way to fix it?

Third and final question - I inserted a section and two subsections to
demonstrate that the numbering of subsections is left-to-right. How can
I make it right-to-left? (Explanation: the PDF shows section "1", and
then subsections "1-1" and "1-2"; reading the numbers from
right-to-left, I need it to show as section "1" and then subsections
"1-1" and "2-1". In the subsection the "1" should come first when
reading rtl.)


Thanks very much for any help.

Bests,

Duncan