On Mon, Aug 15, 2005 at 12:46:55PM +0200, Lars Gullik Bjønnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes:
... > >> If at all possible I'd like to avoid all layout changes now. > >> what are the implications? > > > | 1) LtR should remain unaffected. Business as usual. > | 2) It will be possible to define label strings that depend on the > | language of the document. Currently used to revert the > | section/sub/sub-sub order for Hebrew; but could be generalized. > > > | It looks like this: > > > | LabelString "[EMAIL PROTECTED]@[EMAIL > PROTECTED]@.\arabic{subsection}}" > > > | [Note that "hebrew" refers to language, "arabic" to number type. Quite > | different thing] > > > | So at this point we should decide if we want such an extension to the > | format, and if it should look like this. I dislike hardwiring Hebrew > | into the LyX code, as we have in some places today. Fixing the section > | header bug without this format change would require such hardwiring. > > Note that inside LyX "hebrew" is sometimes used instead of "rtl". > > How is all this solved in 1.3.x? It isn't. These numeric labels just come out in Latin order (which thus violates WYSIWYG, but may be OK with WYSIWYM). But... earlier it worked, I believe. Look at the patch http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/counters.C.diff?r1=1.7&r2=1.8 where I import a large piece of code from somewhere else that does a number of Hebrew things. E.g. enumerate labels, and the letters for appendices become Hebrew. This is probably where I broke it. This stuff was originally in text2.C and looked like this: http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/text2.C.diff?r1=1.241&r2=1.242 where there is at least an attempt to output Hebrew letters for appendix labels. And there 'langtype', is defined, on which enumerate labels depended; later we somehow lost this and they stopped working. So, concludingly, I am pretty sure some of this (at least the enum stuff, and appendix number labels, which my patch doesn't even address yet) worked right around version 1.2. I could prepare a patch only fixing those two things if you like... but the .[Ch] stuff of it would look just the same as in this one. - Martin
pgpgYQRu3ZA51.pgp
Description: PGP signature