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

Attachment: pgpgYQRu3ZA51.pgp
Description: PGP signature

Reply via email to