Linux questions for Jacque

[Phil Davis]

I haven't been following this thread very closely, but I've used the htmlText to 
correctly display Arabic (after reversing the order of the entities). There's 
more to it than that, but... If you can manage the display of Arabic using the 
htmlText field property, maybe something similar could work for Japanese.

Food for thought...
Phil Davis


J. Landman Gay wrote:
> Bob Warren wrote:
> 
>> put the length of field "test" >> 290
>> put the textfont of char 1 to 290 of field "test" >> EMPTY!!!!!!
>> put the textfont of char 2 to 3 of field "test" >> EMPTY
>>
>> Aha!
> 
> Actually, this is probably correct. Fields can have a textfont property 
> independent of the text chunks inside it. That allows you to have a 
> field's textfont set to Courier and a text chunk in the same field set 
> to something else. If you haven't specifically set the textfont of char 
> 1 to 290, then it will be empty and instead it will inherit the field's 
> font.
> 
> What this tells me though is that it is most likely not a unicode issue. 
> I was wondering if your problem might be related to the printing failure 
> of Japanese fonts that popped up in another thread. Guess not.
> 
> One more thing to try: instead of pasting the accented characters from 
> another app, try putting them in using numToChar(). Your fonts may 
> differ from the ones I have on my Mac, but in Courier, for example, the 
> two accented "e"s are numToChar(142) and numToChar(143). I could insert 
> these into a field without pasting by saying:
> 
>   put numToChar(143) into char 1 of fld 1
> 
> I wonder if doing it this way would produce characters that Rev can 
> print. Maybe there is something about pasting from another program that 
> is making a difference.
> 
> If that doesn't work, then a short, 1-card stack with a sample field 
> that fails to print would be a good thing to submit to the QC Center. It 
> should print, RR has verified that, so if it doesn't it needs fixing.
>