Page MenuHomePhabricator

Math rendering poor in RTL
Closed, ResolvedPublic



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:28 PM
bzimport added a project: Math.
bzimport set Reference to bz8002.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

Basically, the Unicode directionality algorithm is hopeless when
you have LTR characters mixed in with punctuation, numerals, and
other LTR/RTL-agnostic stuff. How would this be expected to
display in Arabic? Totally left-to-right, as it would be
rendered in enwiki or wherever? If so, the text direction for
.texhtml should just be forced to LTR.

(For the future, please add long URLs to the URL field so that
the screen doesn't stretch.)

rotemliss wrote:

I think it should be completely LTR, so it's possible to just wrap it to some
span with "dir=ltr". I don't think that CSS is applicable in this case, because
"direction: ltr;" seems to mean elements in the block level.

It can be defined globally, because LTR wikis will render it as LTR anyway, and
RTL wikis should also render it as LTR.

Please provide (attach if possible) a specific example; there doesn't currently seem to be anything relevant at the linked URL.

ayg wrote:

I get the equivalent of

\left(u_{tt} = c^2 \left( u_{xx} + u_{yy} + u_{zz}

instead of the equivalent of

u_{tt} = c^2 \left( u_{xx} + u_{yy} + u_{zz} \right)

I.e., the right parenthesis gets put at the left.

It can be fixed with .texvc { direction: ltr; unicode-bidi: embed; }, if I
remember my testing right. I had ideas of fixing the nonexistence of a real
common CSS file before adding yet another thing to about four different files,
but I haven't gotten around to either fix.

ayg wrote:

Should be fixed in r19143.

Don't you think that this bug should have been marked as "blocking" bug 745, instead of depending on it?