[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CUPS screenshots !

On Friday 14 May 2004 14:39, ahmad khalifa wrote:
> abdulhaq, Ossama Khayat didnt see the arabic text, if you dont mind
> can you also test to confirm this problem ?

I'll have a look over the weekend in shaa' allaah
> if you mean ligature LAM+ALEF, well, the LAA is put inplace of the LAM
> and a space is put inplace of the ALEF. that could be easily fixed in CUPS,
> not like PuTTY where it needed a lot of hacks.

yes, I've been cursed by thinking of arabic in transliteration before learning 
it properly - years later I still sometimes read things in my head from 
left-to-right instead of right-to-left. If any arabic learners are reading 
this, NEVER use transliteration!

I think that once the monspaced font has been found that this extra space will 
be a problem as it might lead to misread words (laa  + shay'an instead of the 
actual word [transliteration - there I go again]).

> the problem with harakat is that they're treated as single space chars, not
> 'NSM' or that they should ride the previous char.
> in CUPS (unlike PuTTY) this can also be easily fixed
> i asked the CUPS guy, and he said there is no plan for composing chars in
> CUPS-1.2. i think the points that need fixing/extending are
> 1. the character structure (lchar_t) should contain a pointer to a list
>      of composing chars. [filter/textcommon.h]
> 2. the input loop should fill the pointer in one with the composing chars
>      as it finds them. it needs to know which are composing chars.
>      [filter/textcommon.c]
> 3. the postscript output loop should also check the pointer in 1.
>      [filter/texttops.c]
> ---the above is for logging, in case i dont get to it !!

In my python program I did nothing special in my character stream to make the 
harakaat appear over the previous character, it just happened. I assumed that 
it was a feature of the font marking the fatHa etc as a diactrical mark. Is 
this not the case then?