Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I have a problem using Polyglossia in Hebrew: While defining main language as Hebrew, my tables are not numbered in the caption(It appraes as just "Table" (טבלה) instead of "Table 1" (or "טבלה 1"). If I change the main language back to English - the table is captioned as "Table 1" without problems.

Any suggestions how can I bring back the numbers to the caption of the tables?

MWE:

\documentclass{article}
\usepackage{fontspec}
\usepackage{xunicode}
\usepackage{polyglossia}
\setdefaultlanguage{hebrew}
\setotherlanguage{english}


\setmainfont{David}
\setsansfont{Arial}
\setmonofont{Arial}

\begin{document}

\begin{table}[ht]
\begin{center}
\begin{tabular}{rrr}
  \hline
 & speed & dist \\ 
  \hline
1 & 4.00 & 2.00 \\ 
  2 & 4.00 & 10.00 \\ 
  3 & 7.00 & 4.00 \\ 
  4 & 7.00 & 22.00 \\ 
  5 & 8.00 & 16.00 \\ 
  6 & 9.00 & 10.00 \\ 
   \hline
\end{tabular}
\caption{סתם טבלה}
\end{center}
\end{table}

\end{document}

Thanks for the help!

share|improve this question
    
If I use David CLM as main font I get numbers. –  egreg Jun 2 '12 at 23:27
    
@egreg, Thanks! Now I get an error saying The current roman font does not contain the Hebrew script! Please define \hebrewfont with \newfontfamily. When I add David CLM as hebrewfont, it compiles as gibberish... –  Shmulik Jun 3 '12 at 0:30
1  
OK... Making a progress here. If I use another font (e.g Ezra SIL or Miriam CLM) in the New font famile (\newfontfamily\hebrewfont{Miriam CLM}) the table does get numbered, BUT the colon appears right to the "1" i.e "1:", instead of ":1" as should appear in RTL language. Suggestions? –  Shmulik Jun 3 '12 at 1:20
    
@egreg, It seems you have solved this issue here tex.stackexchange.com/questions/37997/… . How can I get to the table seperator ? –  Shmulik Jun 3 '12 at 2:04
    
I don't know what to say: with David CLM as main font I don't need to declare a \hebrewfont family and I get "הלבט םתס :1 הלבט", but reversed. That is, the colon is to the left of 1. –  egreg Jun 3 '12 at 9:01
show 4 more comments

3 Answers

up vote 1 down vote accepted

No problem here using MAC OSX 10.7.4 and TeXLive 2012:

\documentclass{article}
\usepackage{polyglossia}
\setdefaultlanguage{hebrew}
\setotherlanguage{english}


\setmainfont{Adobe Hebrew}
\setsansfont{Arial}
\setmonofont{Arial}

\begin{document}

\begin{table}[ht]
\begin{center}
\begin{tabular}{rrr}
  \hline
 & speed & dist \\ 
  \hline
1 & 4.00 & 2.00 \\ 
  2 & 4.00 & 10.00 \\ 
  3 & 7.00 & 4.00 \\ 
  4 & 7.00 & 22.00 \\ 
  5 & 8.00 & 16.00 \\ 
  6 & 9.00 & 10.00 \\ 
   \hline
\end{tabular}
\caption{סתם טבלה}
\end{center}
\end{table}

\end{document}

here is the output I get which is perfectly fine:

enter image description here

UPDATE:

@Ulrike: This should be your minimal example:

\documentclass{minimal}
\TeXXeTstate=1
\font\body="Adobe Hebrew:script=hebrew" at 12pt % replace "Adobe Hebew" with some other Hebrew font
\begin{document}
\hbox{\beginR\body
טבלה
1:
סתם טבלה
\endR}
\end{document}

Using TeXLive 2012 on Mac OS X 10.7.4, this is what I get which is the expected behaviour:

enter image description here

If you get anything else, then that is the bug of MiKTeX. Indeed, MiKTeX has included a buggy version of XeTeX binary for several years. For details, see Here.

share|improve this answer
    
Vafa, thanks. I put my money that it has something to do with MikTeX's Xelatex or Windows fonts, as You and @egreg compiled it perfectly. The fact that the problem is for table caption is irrelevant, as it also appears in Figures and Theorems captions. I'd be glad to hear from Win-PC Polyglossia RTL user some hints... –  Shmulik Jun 3 '12 at 12:38
    
Perhaps a MiKTeX bug like this one: tex.stackexchange.com/questions/52575/… –  Vafa Khalighi Jun 4 '12 at 2:45
    
@Vafa: Well you complicated things a bit by introducing the script=hebrew. I don't have the adobe font but made some tests with Erza SIL: Without the script-option ` 123: ` is typed left-to-right and so give 123:. With the script=.. ` 123: ` is handled like the mix abמאוד in my example: glyphs are lost and the result is :12. The :1 from your example disappears completly. So there is a difference between Miktex (on Windows) and TeXLive (on MaC OS). But if this means that one of both is buggy (and which one) I don't dare to say. –  Ulrike Fischer Jun 4 '12 at 15:54
    
@Ulrike: That is the main point. without script option, my output is exactly the same as yours. But with script option, it makes sense that we both get the expected behaviour, if I get the expected behaviour but you do not, would not that be the bug of MiKTeX? can you recall this? (It is actually the same bug which has not been fixed yet, the bug did not exist in earlier versions of MiKTeX): tug.org/mailman/htdig/xetex/2011-July/020885.html –  Vafa Khalighi Jun 4 '12 at 16:19
    
@Vafa: But I don't know what is the "expected" behaviour. You are mixing in one word "western" glyphs (the numbers 123), which should be printed from left to right in the order of the input with "hebrew glyphs" which should be printed in reversed order. It sounds easy to claim that "123:" should be printed as ":123". But what is with "12:30:80"? Btw: I don't think that miktex does something special in its xetex implementation. By guess is that some library is different for windows than for mac os. –  Ulrike Fischer Jun 4 '12 at 17:06
show 14 more comments

@Eyal, @Vafa:

Regarding the problem with the separator. I don't know if it is due to a bug in miktex as I don't know what is the indented or wanted behaviour (how e.g. should the number 123 be printed in hebrew? As 123 or 321?). But if it is bug then the first step is to simplify the problem. Examples which relies on fontspec, polyglossia, bidi and unknown fonts will not be useful in a bug report.

I boiled down the problem to the following:

\documentclass{article}
%\font\test="Arial Unicode MS"
\font\test="Ezra SIL"
\TeXXeTstate=1

 \chardef\popDirection"202C
 \chardef\forceLtoR"202D
 \chardef\forceRtoL"202E
\begin{document}
%non-unicode font
\beginR
abc 123:
\endR

%unicode-font
\test
abc 123:  456\mbox{}:  מאוד abמאוד :מאוד

\beginR
abc 123:  456\mbox{}:  מאוד abמאוד :מאוד
\endR

\beginR
\forceRtoL 123:  
\forceRtoL abמאוד
\endR

\end{document}

This give this result for me with miktex 2.9 (the result with arial unicode is similar):

enter image description here

It is obvious that as soon as unicode-fonts are used the direction inside "words" depends on the unicode plane of the chars involved: Words with numbers or chars like "abc" together with punctuation chars like colons or dots are printed left-to-right even in a RTL context (and the other way round). Words which mix chars from left-to-right and right-to-left-planes can swallow preceding chars due to the direction change. What do you get on TeXLive?

share|improve this answer
    
Numbers mustn't be reversed. –  egreg Jun 4 '12 at 14:26
    
See my updated answer. –  Vafa Khalighi Jun 4 '12 at 14:33
add comment

I use MiKTeX 2.9 on Windows XP.

Here's what I get with Ulrike's MWE (with FrankRuehl as the font):

screenshot

and this is without the script=hebrew (as per Vafa's comment):

screenshot

so, no number glyph and no colon glpyh in the first image, and they appear again in the second image. Also, there's the separator bug Shmulik linked to. Finally, note the spacing differences - the glyphs are not replaced with whitespace of the same width - but there is some extra space in the first example.

With Shmulik's code + slight change of the font command I get some strange behavior:

\documentclass{article}
\usepackage{fontspec}
\usepackage{xunicode}
\usepackage{polyglossia}
\setdefaultlanguage{hebrew}
\setotherlanguage{english}

%\setmainfont{David}
\newfontfamily\hebrewfont{David}
\setsansfont{Arial}
\setmonofont{Arial}

\begin{document}
\begin{table}[ht]
\begin{center}
\begin{tabular}{rrr}
  \hline
 & speed & dist \\
  \hline
1 & 4.00 & 2.00 \\
  2 & 4.00 & 10.00 \\
  3 & 7.00 & 4.00 \\
  4 & 7.00 & 22.00 \\
  5 & 8.00 & 16.00 \\
  6 & 9.00 & 10.00 \\
   \hline
\end{tabular}
\caption{סתם טבלה}
\end{center}
\end{table}
\end{document}

screenshot

The non-Hebrew characters do seem to be David, but the Hebrew is in some other font.

share|improve this answer
    
How do you want that to be correct when there is no Script=Hebrew option in your \newfontfamily\hebrewfont{David}? –  Vafa Khalighi Jun 4 '12 at 17:33
    
Oh, well that gives you: fontspec warning: "script-not-exist" Font 'David' does not contain script 'Hebrew'. And with some other fonts it works without the [Script=Hebrew]. –  einpoklum Jun 5 '12 at 18:37
    
That is the main point. The font should contain Hebrew script, if it does not contain Hebrew script and you do not use it, things do not work properly. As an example try my minimal example, replace Adobe Hebrew with Ezra SIL, run xelatex on it and see the output, second time, remove script=hebrew: font\body="Ezra SIL" at 12pt. Now compare the outputs. Can you see what Hebrew script effects has? –  Vafa Khalighi Jun 6 '12 at 4:48
    
@VafaKhalighi: done. Also, David certainly does contain Hebrew script, I use it all the time in Word Processing. Perhaps that's misreported somehow, or misunderstood by MikTeX. –  einpoklum Jun 7 '12 at 19:58
    
Containing Hebrew glyphs is quite different to containing Hebrew Script (this is like a script tag that the font should have). Even if a font does not contain Hebrew script but contains Hebrew glyphs, you are still able to typeset Hebrew with it but not properly. I do not think, this is misreported or misunderstood. For more details, please see microsoft.com/typography/otfntdev/hebrewot/appen.aspx –  Vafa Khalighi Jun 8 '12 at 5:27
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.