Internationalization and cvs

[Asger K. Alstrup Nielsen]

Hi fellow LyXers from all over the world,

These days, we are overwhelmed with patches that extend the scope
of LyX to Hebrew, Chinese, Korean, Japanese, and what have you.
This is great, and very much appreciated.

Now, the question is how to handle this.  It seems to me that the
Hebrew patch is "backwards" compatible in the sense that it does
not affect the left-to-right 8-bit languages, except maybe for a
small performance penalty.  However, several voices say that
paragraph-level language support is important, so it seems that
there might be a fair amount of development needed to get that.
Therefore, the best solution might be to create a Hebrew-cvs
branch for this, which for starters will use the document-wide
solution.

Similarly for the multi-byte encoding stuff:  The authors ask
for a separate cvs-branch, and since I have not seen the patch 
yet, this seems like a good idea.

So it's time to create a few cvs-branches.

As I understand the issue, we need two new branches:

One for Hebrew, and one for the multi-byte encoding languages.

Is this the correct understanding?

What would you like the branches to be called?

Lgb, how long will it take to create those branches and give
the relevant people write access to the repository?

Greets,

Asger

Re: Internalization

[Asger K. Alstrup Nielsen]

  About i18n, I've read the  "encoding.lyx"  article written by Asger
 Alstrup Nielsen.  (By the way, the file is no longer available at the URL
 where I got it before.  Is it no longer available?)  The article is

Good question.  Lgb, what happened with the old ftp.devel.lyx.org content?

  For translations in menus/messages (ie. excluding documentations)
 which are encoded in multi-byte encoding, eg for Asian languages, isn't
 it better that these translations should be encoded in Unicode?

Yes, this is probably better if gettext can support this.

Regarding the menus, there are plans to move the text from the
gettext framework to separate configuration files.  This work
has actually been done in the old development branch, so all
we need to do is to backport it to the new development branch.
This is on schedule for 1.1.5, I think.
When this is done, it would be natural to rethink the I18N issue,
and see if we can handle Unicode in the configuration files that
control the menus (and the other configuration files.)

Regarding the po-files:  I don't think gettext can handle Unicode
natively, so we probably have to use UTF8 or a similar 8-bit encoding.

  But of course, this would raise a second question: how is one
 supposed to edit in Unicode?  With what editor?  I just know yudit but I
 just managed to make it work partially.  And how are .po files saved?  In
 utf-7, utf-8 or UCS-2?  Probably not in UCS-2, I think, but I might be
 wrong.  Who knows?

I don't know how we should handle this issue. I hope yudit is ready for
the task.

Greets,

Asger

DEBUG_AS_DEFAULT

[Jean-Marc Lasgouttes]

Hello there,

I was about to remove the --with-debug flag of configure and noticed
that Allan has actually been using DEBUG_AS_DEFAULT in bullet code.
Wouldn't it make sense to condition on DEVEL_VERSION instead? At least
we would be sure that the invariants are actually tested.

Another solution would be to add an --enable-assertions flag which
defaults to 'yes' for development versions, but which can be turned
off (for speed reasons).

What do you think?

JMarc

Re: Internalization

[Shigeru Miyata]

"Seak, Teng-Fong" [EMAIL PROTECTED] wrote:

 Actually, newer versions of XFree86 support already natively Unicode, so
 do a lot of commercial X (if not all).

It also introduces Big5 support.  Other multibyte encodings have been
supported for quite some time.

 So I suppose characters (eg in
 menus) are displayed using Unicode.

What gain do we have?

  However, people still use Big5 as
 traditional Chinese encoding.  Convesion from Big5 to and from Unicode
 isn't quite straightforward as from Latin-1 to and from Unicode.  If the
 translation is done in Big5, there will be a lot of unnecessary
 conversion Big5 - Unicode.

On the contrary.  In order to communicate with existing applications,
people continue using traditional encodings as document languages.
So if we use Unicode here, then we will have to have unnecessary
conversions.

   That's why I ask if it's better to use
 Unicode as the underlying encoding.  I take Chinese as an example, but
 the argument can be very well applied to Japanese, Korean and any
 language encodings other than Latin-1.
[...]
 And how are .po files saved?

Any encoding you like as far as it is a superset of 7 bit ASCII.
(utf-8, EUC, Big5, Shift-JIS, KS...)
However, FYI, XForms cannot draw 16 bit character strings.

Regards,
SMiyata

Re: Hebrew support for LyX

[Shigeru Miyata]

"Seak, Teng-Fong" [EMAIL PROTECTED] wrote:

  Chinese (as well as Japanese and Korean) can also be written from right to
 left, even though this isn't very common nowadays.  Actually, in tradition,
 Chinese is written from top to the bottom, then from right to left.  But I
 don't think Latex is able to support this :-)

Theoretically speaking it is of course possible.  However, dimensions
and
other TeX registers are scarce resources and if you implement vertical
typesetting only by macros, then you are more likely to encounter
"TeX capacity exceeded..." errors.  But you can check arabtex macro
package where RTL typesetter is implemented all by macros.
(So arabtex package does not require special TeX compilers and can
typeset
both Arabic and Hebrew.  While hebrew macro package requires eTeX and/or
TeX--Xet and only supports Hebrew.)

In fact, the standard TeX compiler only has LTR_TTB (characters are
written from left to right to form a line; lines are placed from top to
bottom to form a page) primitive.  The eTeX compiler has both LTR_TTB
and RTL_TTB primitives.  The pTeX compiler (Japanized version, not
available from CTAN) and possibly the hTeX compiler have LTR_TTB and
TTB_RTL primitives.  The omega compiler supports LTR_TTB, RTL_TTB,
TTB_RTL (for Chinese, Japanese, etc.) and TTB_LTR (for Mongolian)
primitives.

Regards,
SMiyata

Re: Internationalization and cvs

[Jules Bean]

On Wed, 15 Dec 1999, Andre' Poenitz wrote:

 
 Concerning the multi-byte encoding: We should have a discussion whether
 it is sensible to use Unicode internally. The world is changing and last
 years' arguments won't fit anymore. We could get rid of almost all of
 the encoding stuff at the price of double sized buffers plus quite a bit
 of work. But in the end thing would be much simpler 

My instinct says that most people aren't going to care in the slightest
about a doubling of internal buffer sizes.  The combination of cheap
memory, cheap hard disks, and sensible VM systems makes this not much of
an issue, IMO.

Of course, if we're space-paranoid we could use UTF, or whatever it's
called.  That's more work, though.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: Internationalization and cvs

[Jean-Marc Lasgouttes]

 "Jules" == Jules Bean [EMAIL PROTECTED] writes:

Jules On Wed, 15 Dec 1999, Andre' Poenitz wrote:
  Concerning the multi-byte encoding: We should have a discussion
 whether it is sensible to use Unicode internally. The world is
 changing and last years' arguments won't fit anymore. We could get
 rid of almost all of the encoding stuff at the price of double
 sized buffers plus quite a bit of work. But in the end thing would
 be much simpler

Jules My instinct says that most people aren't going to care in the
Jules slightest about a doubling of internal buffer sizes. The
Jules combination of cheap memory, cheap hard disks, and sensible VM
Jules systems makes this not much of an issue, IMO.

I think it should not be very difficult to choose the size of
characters at compile time. We define LChar to be the unit character,
and operate on that.

JMarc

Re: Internationalization and cvs

[Andre' Poenitz]

 My instinct says that most people aren't going to care in the slightest
 about a doubling of internal buffer sizes.  The combination of cheap
 memory, cheap hard disks, and sensible VM systems makes this not much of
 an issue, IMO.

*grin* Well, I did not want to write obvious things ;-)

Andre'

PS: External 8bit is another matter... Interoperation...

--
Andre' Poenitz .. [EMAIL PROTECTED]

Re: Internationalization and cvs

[Greg Lee]

On Wed, 15 Dec 1999, Asger K. Alstrup Nielsen wrote:
...
 not affect the left-to-right 8-bit languages, except maybe for a
 small performance penalty.  However, several voices say that
 paragraph-level language support is important, so it seems that

Surely those voices didn't mean paragraph-level support without
also sentence- and word-level support.  When you cite from a
different language, the citation is obviously not always
going to be a separate paragraph.
...

Greg Lee [EMAIL PROTECTED]

Re: Internationalization and cvs

[Asger K. Alstrup Nielsen]

 Surely those voices didn't mean paragraph-level support without
 also sentence- and word-level support.  When you cite from a
 different language, the citation is obviously not always
 going to be a separate paragraph.

As it happens, sub-paragraph-level support is markedly more
difficult than paragraph-level support, so don't hold your
breath.

It's similar to the old discussion (i.e. flame war) of why the 
ERT mode is not collapsable: The reason is that character-level 
(technically equivalent to sentence-level) support is much more 
difficult than paragraph-level.
One reason is that paragraph-level requires only 1D formatting
(because a paragraph spans the entire width of the screen), while
character-level requires 2D formatting.

Having said that, the old development branch actually had some
support of character-level collapsable insets implemented at
a developers meeting in Mexico by Juergen and Alejandro, so it
*is* possible to achieve.

This extrapolates to character-level RTL support: Of course it is
possible, but it's very complicated.  How should lines wrap?
What about nested quotes: An English document with quote in Hebrew,
which itself contains an English quote.

What about search/replace?  What about cut/paste?

There are many issues to consider.

Fortunately, most of them have been addressed by the Unicode standard,
but it still is a lot of work to understand and implement.  I have the 
Unicode book with part of the recipe, so if anybody have technical 
questions, please let me know and I'll see what I can find out.

Greets,

Asger

Re: DEBUG_AS_DEFAULT

[Asger K. Alstrup Nielsen]

 Another solution would be to add an --enable-assertions flag which
 defaults to 'yes' for development versions, but which can be turned
 off (for speed reasons).

This is the better solution, because the distinction between development
versions and stable releases is being blurred these days. That implies
that it is much more sensible to want a fast development version, even
if it is considered a (stable) development version.

Greets,

Asger

Re: Strange feature

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Is this also treu after reading the file again? What keynap are
Lars you using?

Lars Seems like Lyx does not think that this char can be directly
Lars showed/dispplayed, and used a InsetLatexInset to show it.

After debugging this a bit, it seems that you broke the parsing of
cdef files with the new regexp stuff. The problem is that you do not
handle backslash escapes, and \\\"{o} is kept as is in chset map,
instead of transforming it to \"{o}.

It does not seem to me that the new parsing is significantly better
that plain old lyxlex... 

Moreover, your regexp "^([12][0-9][0-9])[ \t]+\"([^ ]+)\".*" does not
allow for spaces at the beginning of a line, but allows any junk at
the end of a line... And any wrongly formed line is silently ignored
as if it were a comment. Frankly, I think the old code was much better
(at least for _this_ particular file: there might be advantages to
regexps in other cases). If you really like regexps, you should design
a regexp-based parse class, which handles all the robustness matters.

JMarc

Re: cleanup

[Andre' Poenitz]

 
 IMHO, you either should use only tabs to indent, or only spaces.
 Otherwise, you'll have problems when:
  * Showing in a proportional font
  * Showing with a different tab setting (!=3D 8)

Erm, exactly that is the patch supposed to do. Since most of the lyx
sources are tab-indented I changed the remaining 8-space indentation to
tabs. Does this sound wrong?

Andre'

--
Andre' Poenitz .. [EMAIL PROTECTED]

Re: FILE - ostream

[Jean-Marc Lasgouttes]

 "Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:

Asger The LaTeXWriter was not written. However, it would be an easy
Asger task to do it. The AsciiWriter exists in the old development
Asger branch, and only needs to be extended with a few routines
Asger before a usable LaTeXWriter is ready. Now, if only I had
Asger time...

OK. I grant you one week. Is that enough? %-]

JMarc

Re: small docbook patch

[Jean-Marc Lasgouttes]

 "Andre'" == Andre' Poenitz [EMAIL PROTECTED] writes:

 + ofs  "!-- DocBook file was created by LyX 1.1 (C) 1995-1999\n"
  "by "  userName  " "  date()  " --\n";

Andre' Aehm.. sorry, forgot one. "userName"? I thought big brother
Andre' was dropped a few weeks ago ;-)

Well spotted. Jose', would you care providing a sensible header
without user name and copyright, before I change it myself?

JMarc

Re: Strange feature

[Andre' Poenitz]

 Lars Is this also treu after reading the file again? What keynap are
 

This is about the third or fourth mail from Lars that gets cited in the
list although I did not receive the original. Since the question looks
like Lars asked me (it was my problem) I should have received at least
one copy, shouldn't I?

Any idea? I am pretty sure Lars is not in any kind of killfile here...

Andre'

Re: Strange feature

[Jean-Marc Lasgouttes]

 "Andre'" == Andre' Poenitz [EMAIL PROTECTED] writes:

Lars Is this also treu after reading the file again? What keynap are


Andre' This is about the third or fourth mail from Lars that gets
Andre' cited in the list although I did not receive the original.
Andre' Since the question looks like Lars asked me (it was my
Andre' problem) I should have received at least one copy, shouldn't
Andre' I?

Andre' Any idea? I am pretty sure Lars is not in any kind of killfile
Andre' here...

That's strange... The message is correctly archived at
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg08012.html

I append the header of the message to this message. The only notable
thing is that it has been sent to lyx-devel but not CC'd to you (which
is rather a good idea).

JMarc

Mail-from: From [EMAIL PROTECTED]
 Wed Dec 15 02:04:03 1999
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78])
by fantomas.inria.fr (8.8.5/8.8.7) with ESMTP id CAA09638
for [EMAIL PROTECTED]; Wed, 15 Dec 1999 02:04:03 +0100 (MET)
Received: from wierdlmpc.msci.memphis.edu (wierdlmpc.msci.memphis.edu [141.225.11
.87])
by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id CAA08816
for [EMAIL PROTECTED]; Wed, 15 Dec 1999 02:04:02 +0100 (MET
)
Received: (qmail 14883 invoked by uid 514); 15 Dec 1999 01:04:12 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Unsubscribe: mailto:lyx-devel-unsubscribe-Jean-Marc.Lasgouttes=inria.fr@lis
ts.lyx.org
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 14873 invoked from network); 15 Dec 1999 01:04:11 -
To: [EMAIL PROTECTED]
Subject: Re: Strange "feature"
References: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
Date: 15 Dec 1999 02:03:46 +0100
In-Reply-To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
X-Mailer: Gnus v5.5/Emacs 20.3
Lines: 20
Xref: fantomas.inria.fr lyx-devel:1968
X-Gnus-Newsgroup: lyx-devel:1968   Wed Dec 15 10:31:15 1999

Re: cleanup

[Martin Norbäck]

Wed Dec 15 1999, Andre' Poenitz -
  
  IMHO, you either should use only tabs to indent, or only spaces.
  Otherwise, you'll have problems when:
   * Showing in a proportional font
   * Showing with a different tab setting (!=3D 8)
 
 Erm, exactly that is the patch supposed to do. Since most of the lyx
 sources are tab-indented I changed the remaining 8-space indentation to
 tabs. Does this sound wrong?

Aha, sorry, my mistake. You are a good guy after all!

n.

-- 
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ]
Opinions expressed above are mine, and not those of my future employees.
  Skingra er! Det finns ingenting att förstå!

 PGP signature

Re: small docbook patch

[Jose Abilio Oliveira Matos]

On Wed, Dec 15, 1999 at 04:10:47PM +0100, Jean-Marc Lasgouttes wrote:
  "Andre'" == Andre' Poenitz [EMAIL PROTECTED] writes:
 
  + ofs  "!-- DocBook file was created by LyX 1.1 (C) 1995-1999\n"
   "by "  userName  " "  date()  " --\n";
 
 Andre' Aehm.. sorry, forgot one. "userName"? I thought big brother
 Andre' was dropped a few weeks ago ;-)
 
 Well spotted. Jose', would you care providing a sensible header
 without user name and copyright, before I change it myself?

  Indeed. Sorry for replying so late and thanks for Andre' for pointing this...

  The correct header should be something like

  ... + ofs  "!-- "  the_header  " --\n";

  Now replace the_header with something that is according to our policy guides
( oops, this isn't debian... forget it ;).

  I still think that the date should go in this comment. Regarding the choice of
a sensible header I will agree with your choice.

 JMarc

-- 
José

Re: small docbook patch

[Jose Abilio Oliveira Matos]

On Tue, Dec 14, 1999 at 03:50:38PM +0100, Jean-Marc Lasgouttes wrote:
  "Jose" == Jose Abilio Oliveira Matos [EMAIL PROTECTED] writes:
 
 Jose Content-Type: text/plain; charset=iso-8859-1
 Jose Content-Transfer-Encoding: 8bit
 
 Jose Hi, I have tested the latest cvs and lyx. With the docbook
 Jose example file lyx crashes.
 
 Jose Debuging it is possible to see that some assertion is raised
 Jose where a non initialised string is accessed, throught the []
 Jose operator.
 
 OK, I just commited it.

  Thanks.
 
 JMarc
 
 PS: you could probably ask Lars for cvs access...

  I will, and since no is volunteer I volunteer myself to change the sgml load
stuff. Your plan (in a previous mail message) is a good starting point. As I see
it in the Changelog this hasn't been done, or am I wrong?

-- 
José

Re: small docbook patch

[Jean-Marc Lasgouttes]

 "Jose" == Jose Abilio Oliveira Matos [EMAIL PROTECTED] writes:

Jose   I will, and since no is volunteer I volunteer myself to change
Jose the sgml load stuff. Your plan (in a previous mail message) is a
Jose good starting point. As I see it in the Changelog this hasn't
Jose been done, or am I wrong?

You are right. I've been too lazy to do it.

JMarc

Re: Hebrew support for LyX

[Tsur Dekel]

 
 On Tue, Dec 14, 1999 at 01:19:23PM +0100, Asger K. Alstrup Nielsen wrote:
  
  Yes, this patch is very cool.  Hebrew support can be considered a FURF,
  and it's great to see somebody do something about it.
 
 Yay!
 
 Dekel, how is this patch related to TeX--XeT? I seem to remember you needed
 more than just a Hebrew font to write hebrew in LaTeX.

The new TeX distributions come with e-TeX which replaces TeX--XeT.
See ftp://ftp.cc.huji.ac.il/pub/tex/unix/new/INSTALLATION.txt 
for instruction on adding Hebrew support to LaTeX


To use my LyX patch, you need to add the following line to lyxrc
\latex_command elatex

You also need to select a Hebrew font with the \screen_font_roman
command and use a Hebrew keymap.

po-Patches, plus some bugs...

[Peter Suetterlin]

  Hi Folks,

as promised, I took some time to look through the german po-files.
Attached are 2 patches for de.po and de_menus.bind.
They are against 1.1.4pre1.

Furthermore I found 2 (minor) glitches:

 - The ballon tool tips are not translated.  I'm not sure wether this
   has ever since been the case, but i thought they have been at some
   point... 

 - When using a different keymap table (in my case german):
   The umlauts (ä,ö etc.) show up quite strange (like painted by LyX
   itself, not using the font), the sharp s (ß) is written as \{ss}
   (*not* in TeX-Mode!).
   Also, the german keyboard table needs the AltGr key for some
   characters (namely |,\, and @);  This seems not to be supported by
   that map.  

Sorry if those already have been reported - I'm only following the list
very loosely.
Cheers,

  Pit

-- 
~~
Dr. Peter "Pit" Suetterlin http://www.astro.uu.nl/~suetter
Sterrenkundig Instituut Utrecht
Tel.: +31 (0)30 253 5225   [EMAIL PROTECTED]
__

 de_menus.diff.gz
 de.po.diff.gz

Re: po-Patches, plus some bugs...

[Jean-Marc Lasgouttes]

 "Peter" == Peter Suetterlin [EMAIL PROTECTED] writes:

Hi Pit,

Thanks for the patches, I'll commit them soon.

Peter  - The ballon tool tips are not translated. I'm not sure wether
Peter this has ever since been the case, but i thought they have been
Peter at some point...

They used to be translated. It is probably due to Lars recent changes.

Peter  - When using a different keymap table (in my case german): The
Peter umlauts (ä,ö etc.) show up quite strange (like painted by LyX
Peter itself, not using the font), the sharp s (ß) is written as
Peter \{ss} (*not* in TeX-Mode!). 

This bug has been identified, and thus should be fixed soon.

Peter Also, the german keyboard table
Peter needs the AltGr key for some characters (namely |,\, and @);
Peter This seems not to be supported by that map.

What is the modifier associated to AltGr?

JMarc

Re: Internationalization and cvs

[Greg Lee]

On Wed, 15 Dec 1999, Asger K. Alstrup Nielsen wrote:

  Surely those voices didn't mean paragraph-level support without
  also sentence- and word-level support.  When you cite from a
  different language, the citation is obviously not always
  going to be a separate paragraph.
 
 As it happens, sub-paragraph-level support is markedly more
 difficult than paragraph-level support, so don't hold your
 breath.

Ok, I'm not.  I'm just wondering whether paragraph-level support
only is going to be useful enough to potential users to make
it worthwhile embarking on.  Worth your while, of course, is
what I mean, since I'm not a Lyx developer.  But it would be
sort of irritating for you to get it all worked out and then
have those MSDOS users you were trying to seduce say, Oh,
we didn't think to mention that we need to cite words too ...

Greg Lee [EMAIL PROTECTED]

Re: Strange feature

[Lars Gullik Bjønnes]

"Andre' Poenitz" [EMAIL PROTECTED] writes:

|  Lars Is this also treu after reading the file again? What keynap are
|  
| 
| This is about the third or fourth mail from Lars that gets cited in the
| list although I did not receive the original. Since the question looks
| like Lars asked me (it was my problem) I should have received at least
| one copy, shouldn't I?
| 
| Any idea? I am pretty sure Lars is not in any kind of killfile here...

Please forward this to Andre'...

The mailserver at your site does not allow 8bit characters in mail
heaaders, althogh this is strictly correct in regard to the  RFC
(822?) it is not good in the real world, and there is now really good
reason do disallow 8bit characters in mail headers, pester your
mailadmins to upgrade the mailserver.

(may name is my name is my name)

Lgb

Re: Internalization

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes:

|   About i18n, I've read the  "encoding.lyx"  article written by Asger
|  Alstrup Nielsen.  (By the way, the file is no longer available at the URL
|  where I got it before.  Is it no longer available?)  The article is
| 
| Good question.  Lgb, what happened with the old ftp.devel.lyx.org content?

As told earlier we had a disk crash on nazgul, I managed to save
something but I think that the ftp was one of the things lost, I look
a bit thiugh, I might have something scattered around.

Lgb

Re: DEBUG_AS_DEFAULT

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes:

|  Another solution would be to add an --enable-assertions flag which
|  defaults to 'yes' for development versions, but which can be turned
|  off (for speed reasons).
| 
| This is the better solution, because the distinction between development
| versions and stable releases is being blurred these days. That implies
| that it is much more sensible to want a fast development version, even
| if it is considered a (stable) development version.

I agree "--enable-assertions2 and "--disable-assertions" sounds nice.

Eaasy to implement too, all that needs to be done is in LAssert.h

Lgb

Re: small docbook patch

[Lars Gullik Bjønnes]

Jose Abilio Oliveira Matos [EMAIL PROTECTED] writes:

| On Tue, Dec 14, 1999 at 03:50:38PM +0100, Jean-Marc Lasgouttes wrote:
|   "Jose" == Jose Abilio Oliveira Matos [EMAIL PROTECTED] writes:
|  
|  Jose Content-Type: text/plain; charset=iso-8859-1
|  Jose Content-Transfer-Encoding: 8bit
|  
|  Jose Hi, I have tested the latest cvs and lyx. With the docbook
|  Jose example file lyx crashes.
|  
|  Jose   Debuging it is possible to see that some assertion is raised
|  Jose where a non initialised string is accessed, throught the []
|  Jose operator.
|  
|  OK, I just commited it.
| 
|   Thanks.
|  
|  JMarc
|  
|  PS: you could probably ask Lars for cvs access...
| 
|   I will, and since no is volunteer I volunteer myself to change the sgml load
| stuff. Your plan (in a previous mail message) is a good starting point. As I see
| it in the Changelog this hasn't been done, or am I wrong?
| 
| -- 
| José

Actaully you have had an account and "access" to cvs  almost for ever,
but has not asked to be given karma. Consider your karma high enough
now.

Lgb

Anybody tried to get the lyx-devel branch running on NT ?

[Dr. Ing. Roland Krause]

Has anybody experiences to share ? 
I am having problems with the autogen.sh script, seems that some things
are still missing on my system. 

When I run autogen.sh I get some messages (file attached), then when I
try to run 
./configure I see the following:

loading cache ./config.cache
./configure: 533: Syntax error: word unexpected (expecting ")")

My system is NT-4 SP4 with cygwin-beta 20,mumit khan's gcc-2.95-2,
autoconf, automake everything fresh installed from original sources
today. 
checked out the lyx-devel tree today Dec 15th. 

This looks like an automake problem to me. 
Thanks for any hints.

Roland

Building macros.
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_LC_MESSAGES' not found in library
Building config header template
Building Makefile templates
configure.in: 5: required file `src/config.h.in' not found
automake: src/Makefile.am: C++ source seen but `CXX' not defined in `configure.in'
automake: src/mathed/Makefile.am: C++ source seen but `CXX' not defined in 
`configure.in'
automake: src/insets/Makefile.am: C++ source seen but `CXX' not defined in 
`configure.in'
src/support/Makefile.am:7: USE_LYXSTRING does not appear in AM_CONDITIONAL
automake: src/support/Makefile.am: C++ source seen but `CXX' not defined in 
`configure.in'
Building configure
autoconf: Undefined macros:
configure.in:12:AC_VALIDATE_CACHE_SYSTEM_TYPE
configure.in:59:AC_DISABLE_SHARED
configure.in:60:AC_LIBTOOL_WIN32_DLL
run "./configure ; make"
gm4: not found
gnum4: not found
Building lib/configure
Creating POTFILES.in...
done

Re: DEBUG_AS_DEFAULT

[Allan Rae]

On 15 Dec 1999, Lars Gullik Bjønnes wrote:

 "Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes:
 
 |  Another solution would be to add an --enable-assertions flag which
 |  defaults to 'yes' for development versions, but which can be turned
 |  off (for speed reasons).
 | 
 | This is the better solution, because the distinction between development
 | versions and stable releases is being blurred these days. That implies
 | that it is much more sensible to want a fast development version, even
 | if it is considered a (stable) development version.
 
 I agree "--enable-assertions2 and "--disable-assertions" sounds nice.

I agree three.

Actually I wrote Bullet.C about 2-3 years ago and have hardly looked at it
since.  At the time the DEBUG_AS_DEFAULT seemed to mean the equivalent of
the proposed --enable-assertions.

Allan. (ARRae)

Re: Anybody tried to get the lyx-devel branch running on NT ?

[Allan Rae]

From your log of autogen.sh output it appears you need to upgrade to
automake-1.4

Allan. (ARRae)

Internationalization and cvs

[Asger K. Alstrup Nielsen]

Hi fellow LyXers from all over the world,

These days, we are overwhelmed with patches that extend the scope
of LyX to Hebrew, Chinese, Korean, Japanese, and what have you.
This is great, and very much appreciated.

Now, the question is how to handle this.  It seems to me that the
Hebrew patch is "backwards" compatible in the sense that it does
not affect the left-to-right 8-bit languages, except maybe for a
small performance penalty.  However, several voices say that
paragraph-level language support is important, so it seems that
there might be a fair amount of development needed to get that.
Therefore, the best solution might be to create a Hebrew-cvs
branch for this, which for starters will use the document-wide
solution.

Similarly for the multi-byte encoding stuff:  The authors ask
for a separate cvs-branch, and since I have not seen the patch 
yet, this seems like a good idea.

So it's time to create a few cvs-branches.

As I understand the issue, we need two new branches:

One for Hebrew, and one for the multi-byte encoding languages.

Is this the correct understanding?

What would you like the branches to be called?

Lgb, how long will it take to create those branches and give
the relevant people write access to the repository?

Greets,

Asger

Re: Internalization

[Asger K. Alstrup Nielsen]

>  About i18n, I've read the  "encoding.lyx"  article written by Asger
> Alstrup Nielsen.  (By the way, the file is no longer available at the URL
> where I got it before.  Is it no longer available?)  The article is

Good question.  Lgb, what happened with the old ftp.devel.lyx.org content?

>  For translations in menus/messages (ie. excluding documentations)
> which are encoded in multi-byte encoding, eg for Asian languages, isn't
> it better that these translations should be encoded in Unicode?

Yes, this is probably better if gettext can support this.

Regarding the menus, there are plans to move the text from the
gettext framework to separate configuration files.  This work
has actually been done in the old development branch, so all
we need to do is to backport it to the new development branch.
This is on schedule for 1.1.5, I think.
When this is done, it would be natural to rethink the I18N issue,
and see if we can handle Unicode in the configuration files that
control the menus (and the other configuration files.)

Regarding the po-files:  I don't think gettext can handle Unicode
natively, so we probably have to use UTF8 or a similar 8-bit encoding.

>  But of course, this would raise a second question: how is one
> supposed to edit in Unicode?  With what editor?  I just know yudit but I
> just managed to make it work partially.  And how are .po files saved?  In
> utf-7, utf-8 or UCS-2?  Probably not in UCS-2, I think, but I might be
> wrong.  Who knows?

I don't know how we should handle this issue. I hope yudit is ready for
the task.

Greets,

Asger

DEBUG_AS_DEFAULT

[Jean-Marc Lasgouttes]

Hello there,

I was about to remove the --with-debug flag of configure and noticed
that Allan has actually been using DEBUG_AS_DEFAULT in bullet code.
Wouldn't it make sense to condition on DEVEL_VERSION instead? At least
we would be sure that the invariants are actually tested.

Another solution would be to add an --enable-assertions flag which
defaults to 'yes' for development versions, but which can be turned
off (for speed reasons).

What do you think?

JMarc

Re: Internalization

[Shigeru Miyata]

"Seak, Teng-Fong" <[EMAIL PROTECTED]> wrote:

> Actually, newer versions of XFree86 support already natively Unicode, so
> do a lot of commercial X (if not all).

It also introduces Big5 support.  Other multibyte encodings have been
supported for quite some time.

> So I suppose characters (eg in
> menus) are displayed using Unicode.

What gain do we have?

>  However, people still use Big5 as
> traditional Chinese encoding.  Convesion from Big5 to and from Unicode
> isn't quite straightforward as from Latin-1 to and from Unicode.  If the
> translation is done in Big5, there will be a lot of unnecessary
> conversion Big5 <-> Unicode.

On the contrary.  In order to communicate with existing applications,
people continue using traditional encodings as document languages.
So if we use Unicode here, then we will have to have unnecessary
conversions.

>   That's why I ask if it's better to use
> Unicode as the underlying encoding.  I take Chinese as an example, but
> the argument can be very well applied to Japanese, Korean and any
> language encodings other than Latin-1.
[...]
> And how are .po files saved?

Any encoding you like as far as it is a superset of 7 bit ASCII.
(utf-8, EUC, Big5, Shift-JIS, KS...)
However, FYI, XForms cannot draw 16 bit character strings.

Regards,
SMiyata

Re: Hebrew support for LyX

[Shigeru Miyata]

"Seak, Teng-Fong" <[EMAIL PROTECTED]> wrote:

>  Chinese (as well as Japanese and Korean) can also be written from right to
> left, even though this isn't very common nowadays.  Actually, in tradition,
> Chinese is written from top to the bottom, then from right to left.  But I
> don't think Latex is able to support this :-)

Theoretically speaking it is of course possible.  However, dimensions
and
other TeX registers are scarce resources and if you implement vertical
typesetting only by macros, then you are more likely to encounter
"TeX capacity exceeded..." errors.  But you can check arabtex macro
package where RTL typesetter is implemented all by macros.
(So arabtex package does not require special TeX compilers and can
typeset
both Arabic and Hebrew.  While hebrew macro package requires eTeX and/or
TeX--Xet and only supports Hebrew.)

In fact, the standard TeX compiler only has LTR_TTB (characters are
written from left to right to form a line; lines are placed from top to
bottom to form a page) primitive.  The eTeX compiler has both LTR_TTB
and RTL_TTB primitives.  The pTeX compiler (Japanized version, not
available from CTAN) and possibly the hTeX compiler have LTR_TTB and
TTB_RTL primitives.  The omega compiler supports LTR_TTB, RTL_TTB,
TTB_RTL (for Chinese, Japanese, etc.) and TTB_LTR (for Mongolian)
primitives.

Regards,
SMiyata

Re: Internationalization and cvs

[Jules Bean]

On Wed, 15 Dec 1999, Andre' Poenitz wrote:

> 
> Concerning the multi-byte encoding: We should have a discussion whether
> it is sensible to use Unicode internally. The world is changing and last
> years' arguments won't fit anymore. We could get rid of almost all of
> the encoding stuff at the price of double sized buffers plus quite a bit
> of work. But in the end thing would be much simpler 

My instinct says that most people aren't going to care in the slightest
about a doubling of internal buffer sizes.  The combination of cheap
memory, cheap hard disks, and sensible VM systems makes this not much of
an issue, IMO.

Of course, if we're space-paranoid we could use UTF, or whatever it's
called.  That's more work, though.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: Internationalization and cvs

[Jean-Marc Lasgouttes]

> "Jules" == Jules Bean <[EMAIL PROTECTED]> writes:

Jules> On Wed, 15 Dec 1999, Andre' Poenitz wrote:
>>  Concerning the multi-byte encoding: We should have a discussion
>> whether it is sensible to use Unicode internally. The world is
>> changing and last years' arguments won't fit anymore. We could get
>> rid of almost all of the encoding stuff at the price of double
>> sized buffers plus quite a bit of work. But in the end thing would
>> be much simpler

Jules> My instinct says that most people aren't going to care in the
Jules> slightest about a doubling of internal buffer sizes. The
Jules> combination of cheap memory, cheap hard disks, and sensible VM
Jules> systems makes this not much of an issue, IMO.

I think it should not be very difficult to choose the size of
characters at compile time. We define LChar to be the unit character,
and operate on that.

JMarc

Re: Internationalization and cvs

[Andre' Poenitz]

> My instinct says that most people aren't going to care in the slightest
> about a doubling of internal buffer sizes.  The combination of cheap
> memory, cheap hard disks, and sensible VM systems makes this not much of
> an issue, IMO.

*grin* Well, I did not want to write obvious things ;-)

Andre'

PS: External 8bit is another matter... Interoperation...

--
Andre' Poenitz .. [EMAIL PROTECTED]

Re: Internationalization and cvs

[Greg Lee]

On Wed, 15 Dec 1999, Asger K. Alstrup Nielsen wrote:
...
> not affect the left-to-right 8-bit languages, except maybe for a
> small performance penalty.  However, several voices say that
> paragraph-level language support is important, so it seems that

Surely those voices didn't mean paragraph-level support without
also sentence- and word-level support.  When you cite from a
different language, the citation is obviously not always
going to be a separate paragraph.
...

Greg Lee <[EMAIL PROTECTED]>

Re: Internationalization and cvs

[Asger K. Alstrup Nielsen]

> Surely those voices didn't mean paragraph-level support without
> also sentence- and word-level support.  When you cite from a
> different language, the citation is obviously not always
> going to be a separate paragraph.

As it happens, sub-paragraph-level support is markedly more
difficult than paragraph-level support, so don't hold your
breath.

It's similar to the old discussion (i.e. flame war) of why the 
ERT mode is not collapsable: The reason is that character-level 
(technically equivalent to sentence-level) support is much more 
difficult than paragraph-level.
One reason is that paragraph-level requires only 1D formatting
(because a paragraph spans the entire width of the screen), while
character-level requires 2D formatting.

Having said that, the old development branch actually had some
support of character-level collapsable insets implemented at
a developers meeting in Mexico by Juergen and Alejandro, so it
*is* possible to achieve.

This extrapolates to character-level RTL support: Of course it is
possible, but it's very complicated.  How should lines wrap?
What about nested quotes: An English document with quote in Hebrew,
which itself contains an English quote.

What about search/replace?  What about cut/paste?

There are many issues to consider.

Fortunately, most of them have been addressed by the Unicode standard,
but it still is a lot of work to understand and implement.  I have the 
Unicode book with part of the recipe, so if anybody have technical 
questions, please let me know and I'll see what I can find out.

Greets,

Asger

Re: DEBUG_AS_DEFAULT

[Asger K. Alstrup Nielsen]

> Another solution would be to add an --enable-assertions flag which
> defaults to 'yes' for development versions, but which can be turned
> off (for speed reasons).

This is the better solution, because the distinction between development
versions and stable releases is being blurred these days. That implies
that it is much more sensible to want a fast development version, even
if it is considered a (stable) development version.

Greets,

Asger

Re: cleanup

[Martin Norbäck]

Tue Dec 14 1999, Andre' Poenitz ->
> There are quite a few places where spaces had been used instead of tabs.
> I put a patch under
> 
>   http://mathematik.htwm.de/Software/LyX/spacing-patch-1
> 
> or a bit shorter 
> 
>   http://mathematik.htwm.de/Software/LyX/spacing-patch-1.gz
> 
> that changes most occurences of a multiple of eight spaces on the
> beginning of a line into tabs.
> 
> Consider this as an RFITMT ;-)

IMHO, you either should use only tabs to indent, or only spaces.
Otherwise, you'll have problems when:
 * Showing in a proportional font
 * Showing with a different tab setting (!= 8)
 
regards,

Martin

-- 
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ]
Opinions expressed above are mine, and not those of my future employees.
  Skingra er! Det finns ingenting att förstå!

 PGP signature

Re: Strange "feature"

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Is this also treu after reading the file again? What keynap are
Lars> you using?

Lars> Seems like Lyx does not think that this char can be directly
Lars> showed/dispplayed, and used a InsetLatexInset to show it.

After debugging this a bit, it seems that you broke the parsing of
cdef files with the new regexp stuff. The problem is that you do not
handle backslash escapes, and \\\"{o} is kept as is in chset map,
instead of transforming it to \"{o}.

It does not seem to me that the new parsing is significantly better
that plain old lyxlex... 

Moreover, your regexp "^([12][0-9][0-9])[ \t]+\"([^ ]+)\".*" does not
allow for spaces at the beginning of a line, but allows any junk at
the end of a line... And any wrongly formed line is silently ignored
as if it were a comment. Frankly, I think the old code was much better
(at least for _this_ particular file: there might be advantages to
regexps in other cases). If you really like regexps, you should design
a regexp-based parse class, which handles all the robustness matters.

JMarc

Re: cleanup

[Andre' Poenitz]

> 
> IMHO, you either should use only tabs to indent, or only spaces.
> Otherwise, you'll have problems when:
>  * Showing in a proportional font
>  * Showing with a different tab setting (!=3D 8)

Erm, exactly that is the patch supposed to do. Since most of the lyx
sources are tab-indented I changed the remaining 8-space indentation to
tabs. Does this sound wrong?

Andre'

--
Andre' Poenitz .. [EMAIL PROTECTED]

Re: FILE -> ostream

[Jean-Marc Lasgouttes]

> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:

Asger> The LaTeXWriter was not written. However, it would be an easy
Asger> task to do it. The AsciiWriter exists in the old development
Asger> branch, and only needs to be extended with a few routines
Asger> before a usable LaTeXWriter is ready. Now, if only I had
Asger> time...

OK. I grant you one week. Is that enough? %-]

JMarc

Re: small docbook patch

[Jean-Marc Lasgouttes]

> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:

>> + ofs << "\n";

Andre'> Aehm.. sorry, forgot one. "userName"? I thought big brother
Andre'> was dropped a few weeks ago ;-)

Well spotted. Jose', would you care providing a sensible header
without user name and copyright, before I change it myself?

JMarc

Re: Strange "feature"

[Andre' Poenitz]

> Lars> Is this also treu after reading the file again? What keynap are
> 

This is about the third or fourth mail from Lars that gets cited in the
list although I did not receive the original. Since the question looks
like Lars asked me (it was my problem) I should have received at least
one copy, shouldn't I?

Any idea? I am pretty sure Lars is not in any kind of killfile here...

Andre'

Re: Strange "feature"

[Jean-Marc Lasgouttes]

> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:

Lars> Is this also treu after reading the file again? What keynap are
>>

Andre'> This is about the third or fourth mail from Lars that gets
Andre'> cited in the list although I did not receive the original.
Andre'> Since the question looks like Lars asked me (it was my
Andre'> problem) I should have received at least one copy, shouldn't
Andre'> I?

Andre'> Any idea? I am pretty sure Lars is not in any kind of killfile
Andre'> here...

That's strange... The message is correctly archived at
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg08012.html

I append the header of the message to this message. The only notable
thing is that it has been sent to lyx-devel but not CC'd to you (which
is rather a good idea).

JMarc

Mail-from: From [EMAIL PROTECTED]
 Wed Dec 15 02:04:03 1999
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78])
by fantomas.inria.fr (8.8.5/8.8.7) with ESMTP id CAA09638
for <[EMAIL PROTECTED]>; Wed, 15 Dec 1999 02:04:03 +0100 (MET)
Received: from wierdlmpc.msci.memphis.edu (wierdlmpc.msci.memphis.edu [141.225.11
.87])
by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id CAA08816
for <[EMAIL PROTECTED]>; Wed, 15 Dec 1999 02:04:02 +0100 (MET
)
Received: (qmail 14883 invoked by uid 514); 15 Dec 1999 01:04:12 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Unsubscribe: 
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 14873 invoked from network); 15 Dec 1999 01:04:11 -
To: [EMAIL PROTECTED]
Subject: Re: Strange "feature"
References: <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
Date: 15 Dec 1999 02:03:46 +0100
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
X-Mailer: Gnus v5.5/Emacs 20.3
Lines: 20
Xref: fantomas.inria.fr lyx-devel:1968
X-Gnus-Newsgroup: lyx-devel:1968   Wed Dec 15 10:31:15 1999

Re: cleanup

[Martin Norbäck]

Wed Dec 15 1999, Andre' Poenitz ->
> > 
> > IMHO, you either should use only tabs to indent, or only spaces.
> > Otherwise, you'll have problems when:
> >  * Showing in a proportional font
> >  * Showing with a different tab setting (!=3D 8)
> 
> Erm, exactly that is the patch supposed to do. Since most of the lyx
> sources are tab-indented I changed the remaining 8-space indentation to
> tabs. Does this sound wrong?

Aha, sorry, my mistake. You are a good guy after all!

n.

-- 
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ]
Opinions expressed above are mine, and not those of my future employees.
  Skingra er! Det finns ingenting att förstå!

 PGP signature

Re: small docbook patch

[Jose Abilio Oliveira Matos]

On Wed, Dec 15, 1999 at 04:10:47PM +0100, Jean-Marc Lasgouttes wrote:
> > "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:
> 
> >> + ofs << "\n";
> 
> Andre'> Aehm.. sorry, forgot one. "userName"? I thought big brother
> Andre'> was dropped a few weeks ago ;-)
> 
> Well spotted. Jose', would you care providing a sensible header
> without user name and copyright, before I change it myself?

  Indeed. Sorry for replying so late and thanks for Andre' for pointing this...

  The correct header should be something like

  ... + ofs << "\n";

  Now replace the_header with something that is according to our policy guides
( oops, this isn't debian... forget it ;).

  I still think that the date should go in this comment. Regarding the choice of
a sensible header I will agree with your choice.

> JMarc

-- 
José

Re: small docbook patch

[Jose Abilio Oliveira Matos]

On Tue, Dec 14, 1999 at 03:50:38PM +0100, Jean-Marc Lasgouttes wrote:
> > "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
> 
> Jose> Content-Type: text/plain; charset=iso-8859-1
> Jose> Content-Transfer-Encoding: 8bit
> 
> Jose> Hi, I have tested the latest cvs and lyx. With the docbook
> Jose> example file lyx crashes.
> 
> Jose> Debuging it is possible to see that some assertion is raised
> Jose> where a non initialised string is accessed, throught the []
> Jose> operator.
> 
> OK, I just commited it.

  Thanks.
 
> JMarc
> 
> PS: you could probably ask Lars for cvs access...

  I will, and since no is volunteer I volunteer myself to change the sgml load
stuff. Your plan (in a previous mail message) is a good starting point. As I see
it in the Changelog this hasn't been done, or am I wrong?

-- 
José

Re: small docbook patch

[Jean-Marc Lasgouttes]

> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:

Jose>   I will, and since no is volunteer I volunteer myself to change
Jose> the sgml load stuff. Your plan (in a previous mail message) is a
Jose> good starting point. As I see it in the Changelog this hasn't
Jose> been done, or am I wrong?

You are right. I've been too lazy to do it.

JMarc

Re: Hebrew support for LyX

[Tsur Dekel]

> 
> On Tue, Dec 14, 1999 at 01:19:23PM +0100, Asger K. Alstrup Nielsen wrote:
> > 
> > Yes, this patch is very cool.  Hebrew support can be considered a FURF,
> > and it's great to see somebody do something about it.
> 
> Yay!
> 
> Dekel, how is this patch related to TeX--XeT? I seem to remember you needed
> more than just a Hebrew font to write hebrew in LaTeX.

The new TeX distributions come with e-TeX which replaces TeX--XeT.
See ftp://ftp.cc.huji.ac.il/pub/tex/unix/new/INSTALLATION.txt 
for instruction on adding Hebrew support to LaTeX


To use my LyX patch, you need to add the following line to lyxrc
\latex_command elatex

You also need to select a Hebrew font with the \screen_font_roman
command and use a Hebrew keymap.

po-Patches, plus some bugs...

[Peter Suetterlin]

  Hi Folks,

as promised, I took some time to look through the german po-files.
Attached are 2 patches for de.po and de_menus.bind.
They are against 1.1.4pre1.

Furthermore I found 2 (minor) glitches:

 - The ballon tool tips are not translated.  I'm not sure wether this
   has ever since been the case, but i thought they have been at some
   point... 

 - When using a different keymap table (in my case german):
   The umlauts (ä,ö etc.) show up quite strange (like painted by LyX
   itself, not using the font), the sharp s (ß) is written as \{ss}
   (*not* in TeX-Mode!).
   Also, the german keyboard table needs the AltGr key for some
   characters (namely |,\, and @);  This seems not to be supported by
   that map.  

Sorry if those already have been reported - I'm only following the list
very loosely.
Cheers,

  Pit

-- 
~~
Dr. Peter "Pit" Suetterlin http://www.astro.uu.nl/~suetter
Sterrenkundig Instituut Utrecht
Tel.: +31 (0)30 253 5225   [EMAIL PROTECTED]
__

 de_menus.diff.gz
 de.po.diff.gz

Re: po-Patches, plus some bugs...

[Jean-Marc Lasgouttes]

> "Peter" == Peter Suetterlin <[EMAIL PROTECTED]> writes:

Hi Pit,

Thanks for the patches, I'll commit them soon.

Peter>  - The ballon tool tips are not translated. I'm not sure wether
Peter> this has ever since been the case, but i thought they have been
Peter> at some point...

They used to be translated. It is probably due to Lars recent changes.

Peter>  - When using a different keymap table (in my case german): The
Peter> umlauts (ä,ö etc.) show up quite strange (like painted by LyX
Peter> itself, not using the font), the sharp s (ß) is written as
Peter> \{ss} (*not* in TeX-Mode!). 

This bug has been identified, and thus should be fixed soon.

Peter> Also, the german keyboard table
Peter> needs the AltGr key for some characters (namely |,\, and @);
Peter> This seems not to be supported by that map.

What is the modifier associated to AltGr?

JMarc

Re: Internationalization and cvs

[Greg Lee]

On Wed, 15 Dec 1999, Asger K. Alstrup Nielsen wrote:

> > Surely those voices didn't mean paragraph-level support without
> > also sentence- and word-level support.  When you cite from a
> > different language, the citation is obviously not always
> > going to be a separate paragraph.
> 
> As it happens, sub-paragraph-level support is markedly more
> difficult than paragraph-level support, so don't hold your
> breath.

Ok, I'm not.  I'm just wondering whether paragraph-level support
only is going to be useful enough to potential users to make
it worthwhile embarking on.  Worth your while, of course, is
what I mean, since I'm not a Lyx developer.  But it would be
sort of irritating for you to get it all worked out and then
have those MSDOS users you were trying to seduce say, Oh,
we didn't think to mention that we need to cite words too ...

Greg Lee <[EMAIL PROTECTED]>

Re: Strange "feature"

[Lars Gullik Bjønnes]

"Andre' Poenitz" <[EMAIL PROTECTED]> writes:

| > Lars> Is this also treu after reading the file again? What keynap are
| > 
| 
| This is about the third or fourth mail from Lars that gets cited in the
| list although I did not receive the original. Since the question looks
| like Lars asked me (it was my problem) I should have received at least
| one copy, shouldn't I?
| 
| Any idea? I am pretty sure Lars is not in any kind of killfile here...

Please forward this to Andre'...

The mailserver at your site does not allow 8bit characters in mail
heaaders, althogh this is strictly correct in regard to the  RFC
(822?) it is not good in the real world, and there is now really good
reason do disallow 8bit characters in mail headers, pester your
mailadmins to upgrade the mailserver.

(may name is my name is my name)

Lgb

Re: Internalization

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:

| >  About i18n, I've read the  "encoding.lyx"  article written by Asger
| > Alstrup Nielsen.  (By the way, the file is no longer available at the URL
| > where I got it before.  Is it no longer available?)  The article is
| 
| Good question.  Lgb, what happened with the old ftp.devel.lyx.org content?

As told earlier we had a disk crash on nazgul, I managed to save
something but I think that the ftp was one of the things lost, I look
a bit thiugh, I might have something scattered around.

Lgb

Re: DEBUG_AS_DEFAULT

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:

| > Another solution would be to add an --enable-assertions flag which
| > defaults to 'yes' for development versions, but which can be turned
| > off (for speed reasons).
| 
| This is the better solution, because the distinction between development
| versions and stable releases is being blurred these days. That implies
| that it is much more sensible to want a fast development version, even
| if it is considered a (stable) development version.

I agree "--enable-assertions2 and "--disable-assertions" sounds nice.

Eaasy to implement too, all that needs to be done is in LAssert.h

Lgb

Re: small docbook patch

[Lars Gullik Bjønnes]

Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:

| On Tue, Dec 14, 1999 at 03:50:38PM +0100, Jean-Marc Lasgouttes wrote:
| > > "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
| > 
| > Jose> Content-Type: text/plain; charset=iso-8859-1
| > Jose> Content-Transfer-Encoding: 8bit
| > 
| > Jose> Hi, I have tested the latest cvs and lyx. With the docbook
| > Jose> example file lyx crashes.
| > 
| > Jose>   Debuging it is possible to see that some assertion is raised
| > Jose> where a non initialised string is accessed, throught the []
| > Jose> operator.
| > 
| > OK, I just commited it.
| 
|   Thanks.
|  
| > JMarc
| > 
| > PS: you could probably ask Lars for cvs access...
| 
|   I will, and since no is volunteer I volunteer myself to change the sgml load
| stuff. Your plan (in a previous mail message) is a good starting point. As I see
| it in the Changelog this hasn't been done, or am I wrong?
| 
| -- 
| José

Actaully you have had an account and "access" to cvs  almost for ever,
but has not asked to be given karma. Consider your karma high enough
now.

Lgb

Anybody tried to get the lyx-devel branch running on NT ?

[Dr. Ing. Roland Krause]

Has anybody experiences to share ? 
I am having problems with the autogen.sh script, seems that some things
are still missing on my system. 

When I run autogen.sh I get some messages (file attached), then when I
try to run 
./configure I see the following:

loading cache ./config.cache
./configure: 533: Syntax error: word unexpected (expecting ")")

My system is NT-4 SP4 with cygwin-beta 20,mumit khan's gcc-2.95-2,
autoconf, automake everything fresh installed from original sources
today. 
checked out the lyx-devel tree today Dec 15th. 

This looks like an automake problem to me. 
Thanks for any hints.

Roland

Building macros.
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library
aclocal: configure.in: 0: macro `AM_LC_MESSAGES' not found in library
Building config header template
Building Makefile templates
configure.in: 5: required file `src/config.h.in' not found
automake: src/Makefile.am: C++ source seen but `CXX' not defined in `configure.in'
automake: src/mathed/Makefile.am: C++ source seen but `CXX' not defined in 
`configure.in'
automake: src/insets/Makefile.am: C++ source seen but `CXX' not defined in 
`configure.in'
src/support/Makefile.am:7: USE_LYXSTRING does not appear in AM_CONDITIONAL
automake: src/support/Makefile.am: C++ source seen but `CXX' not defined in 
`configure.in'
Building configure
autoconf: Undefined macros:
configure.in:12:AC_VALIDATE_CACHE_SYSTEM_TYPE
configure.in:59:AC_DISABLE_SHARED
configure.in:60:AC_LIBTOOL_WIN32_DLL
run "./configure ; make"
gm4: not found
gnum4: not found
Building lib/configure
Creating POTFILES.in...
done

Re: DEBUG_AS_DEFAULT

[Allan Rae]

On 15 Dec 1999, Lars Gullik Bjønnes wrote:

> "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
> 
> | > Another solution would be to add an --enable-assertions flag which
> | > defaults to 'yes' for development versions, but which can be turned
> | > off (for speed reasons).
> | 
> | This is the better solution, because the distinction between development
> | versions and stable releases is being blurred these days. That implies
> | that it is much more sensible to want a fast development version, even
> | if it is considered a (stable) development version.
> 
> I agree "--enable-assertions2 and "--disable-assertions" sounds nice.

I agree three.

Actually I wrote Bullet.C about 2-3 years ago and have hardly looked at it
since.  At the time the DEBUG_AS_DEFAULT seemed to mean the equivalent of
the proposed --enable-assertions.

Allan. (ARRae)

Re: Anybody tried to get the lyx-devel branch running on NT ?

[Allan Rae]

>From your log of autogen.sh output it appears you need to upgrade to
automake-1.4

Allan. (ARRae)