Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org

[Seak, Teng-Fong]

> Seak>  Finally, few weeks ago I asked in the website's "feedback"
> Seak> section how to "draw" tensor (ie like a vector but with double
> Seak> arrow on top). Have you received this? If it's not available in
> Seak> current version, will it be in the future?
>
> I did not answer because I do not know the answer. Presumably amsmath
> provides such a macro, and if it does, you should be able to use it
> with LyX. However I do not know the specifics.

 Someone sent this to me to tell me how to write a tensor.  As I'm
not a real latex user, I can't say I understand what to do.  Could you,
the developpers of LyX, take a look at this to see if this can be
implemented in LyX?  Thanks in advance.

 Seak


I'm sure someone has done this and put it in a package somewhere.
but you can define a macro in a personal style file (ie save this as
overRightarrow.sty, and load it with usepackage.)

\newcommand\reldoublebar{\mathrel{\smash=}}
\newcommand{\Rightarrowfill@}[1]{%
\m@th \setboxz@h {$#1\reldoublebar$}\ht \z@ \z@
$#1\copy\z@
\mkern -6mu
\cleaders\hbox{$#1\mkern -2mu\box \z@ \mkern -2mu$}\hfill
\mkern -6mu
\mathord \Rightarrow $}
\newcommand{\overRightarrow}{\mathpalette{\overarrow@\Rightarrowfill@}}

You use the command \overRightarrow{T(p,q,r)}

James

Re: shared modules with lyx.

[Shigeru Miyata]

Sorry that I could not answer earlier.

[EMAIL PROTECTED] (Lars Gullik Bj$Bxn(Jnes) wrote:

> btw. did you try --enable-shared on OS/2? How severly did it bomb?

The very first attempt build LyX flawlessly, and then I found there are
no DLL's made but static libraries.  I checked config/ltconfig and then
found to my surprise that the official GNU libtool has finally OS/2
support added in.  I looked into it deeper and found that shared library
generation is diabled for OS/2 platform.  So I activate it and welcomed
by bunches of "Undefined symbol referenced from text segment" message
just as I expected.  I also realized in this build that linker options
are not right at all. I checked config/ltconfig again and found to my
dismay that the linker options for OS/2 are crippled, intentionally IMO.
They are obviously recommended options for emx0.8 when multithreading
support was not free from problems.  I fixed obvious ones but giving
up adding -Zomf, since the corresponding code in libtool 1.2d for OS/2
is too complicated for me to understand and may require a sofisticated
treatment.

Well, attached is my attempt to make libsupport.la linkable here and
error messages I still have.

Regards,
SMiyata
P.S. I like the ImageContainer idea.

 shared.tar.gz

Re: Lyx internationalisation

[Shigeru Miyata]

[EMAIL PROTECTED] (Lars Gullik Bj$Bxn(Jnes) wrote:

> | P.S.  We have to write an inline text inset.
>
> Yes, and some of the code for doing this is in the old devel branch.

I have taken a look.  I'm afraid it is not what I wanted to see.
I was considering the possibility to have short RTL phrases inlined
in LTR paragraphs and vice versa.  I haven't checked the hebrew
macro package, but the arabtex macros support short inlined texts
of this nature for both Arabic and Hebrew.
IMHO Perso-Arabic/Hebrew RTL script support must be distinguished
from the Unicode inset.  The Unicode inset is for inputting texts
in non native languages into a document written in a certain native
language.  While, Perso-Arabic/Hebrew RTL script should be the native
language of a frame document, if it is used.  So my opinion is RTL
paragraphs are not special insets but normal paragraphs.  In other
words, their apparence should be handled by LyXText::Draw().

On the other hand, the Unicode inset must be a lockable inset with
inline/paragraph modes just like the Mathed having inline/display
modes.  I agree that the TeX inset in the old devel branch can be
a basis of the Unicode inset.  I wonder if it is not plausible to
pass the reference to the action rather than the value of the action
to UpdatableInset::LocalDispatch() so that it can be appropriately
modifiable by the LocalDispatch.  This simplifies the implementation
quite a lot, I think.
The requirement in the Unicode inset are input methods and a drawing
routine.  I have an idea for input methods implementation, but, since
it needs quite a few elaboration before it will be in a descent shape,
I won't mention it now.  What I'd like to say now is that as far as
the Xlib supports the typesetting convention for a language, the
Unicode inset must support the language.  As I already mentioned,
XDrawString() and XDrawString16(), (and locale based XmbDrawString()
and XwcDrawString()) determine the drawing directions by the width
of characters.  So if users are guaranteed to have fonts with
negative width characters for Arabic/Hebrew, the scripting in these
languages must be supported.  On the while, we are not going to
support Indic languages in the Unicode inset in the near future:
These languages typeset syllables from left to right, but a vowel
and consonants comprising a syllable are rearranged in a complicated,
context dependent, non-linear way.  TeX macro packages for these
languages come with C source code for preprocessors.  Omega/Lambda
font metric files can store extended attributes for these character
sets.  However, the Xlib does not have any support for drawing
of such scripts.

Regards,
SMiyata