Re: Internalization

[Seak, Teng-Fong]

Shigeru Miyata 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.

 Yup, I know that.  I just mentioned Unicode because I wanted to
high-light its usage. :-)

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

 What gain do we have?

 For LyX, Latin-1 languages and maybe even 8 bit encoded languages, I'm
afraid the gain is quite small.  One obvious advantage is that there's no
need to translate menu/message strings to Unicode from their "original"
encoding.  But for other language, the benefit should be greater.  In
traditional Chinese, Big5 isn't the unique encoding: there're EUC-TW and
XCN-11643-x and some extension created to suit daily usage in HK.  In one
word, it's a mess.  I don't know much about Japanese, but I know that
there're JIS, EUC-JP and Shift JIS.  It seems that one of them is used in
Windows while another one is for Unix/X, right?  Auto JIS is the automatic
recognition, right?  Could it do the job flawlessly?  Don't you find it
frustrated to have so many different encodings?  The same exists for other
languages like Greek and Russian in which one encoding is for Unix/X and the
other is for Windows.

 As there're a significant number of LyX users under Windows, some of
them might want to contribute to the translation too.  Imagine the trouble
they would encounter when some of them edit the translation file under Unix
while others under Windows.  A little carelessness on encoding will mess up
the whole translation file which is very big file.  Luckily, CVS might help
them to save some of their work, but certainly not all.

  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.

 I was talking about menu/message strings encoding.  So there shouldn't
be any problem because we can't cut and paste a menu item :-)

 For document encoding, you're surely correct.  Take Linux as example,
isn't it that the conversion is done by the kernel?  It seems to be so at
least for consoles since kernel uses Unicode internally.

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...)

 By "superset of 7bit ASCII", do you mean that every byte is 7 bit?  If
yes, UTF-7 should be used instead.  On the other hand, Big5 couldn't be used
because the encoding is 8 bit based.

 However, FYI, XForms cannot draw 16 bit character strings.

 I just remembered that in CLE (Chinese Linux Externsion) package, they
manage to display Chinese in LyX.  Or is it KLyX?

 Seak

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Jean-Marc Lasgouttes]

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

Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I
Lars already answered him to add a #include "support/LOstream.h" at
Lars the | beginning of debug.h. I think he is using STL string, and
Lars ostreams | are defined in lyxstring.h, so I did not see that I
Lars missed the header | in my last debug patch.

Lars I think iostream is required to includ ostream so I think
Lars LOstream.h is a bit wrong.

This error occurs _before_ DebugStream.h is included, so iostream has
not been read yet at this point. Have a look at debug.h and you'll see
what I mean (the two static members I added to Debug).

Lars I had some problems with L[IO]stream.h when trying out the gcu
Lars libstd++ libarary.

What kind of problems?

JMarc

lyx-1.1.2, problems under SuSe 5.3 (libc5)

[Uwe Brauer]

Hello

While I had so far no problems in compiling LyX-1.0.3
I was faced for 1.1.2 with a compiler problem, as is seems to me. I did 
not try out 1.1.1. I have attached the error message and the
config.status. 
Thanks
Uwe Brauer


This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:630: checking host system type
configure:651: checking target system type
configure:669: checking build system type
configure:694: checking config.cache system type
configure:723: checking for a BSD compatible install
configure:776: checking whether build environment is sane
configure:833: checking whether make sets ${MAKE}
configure:880: checking for working aclocal
configure:893: checking for working autoconf
configure:906: checking for working automake
configure:919: checking for working autoheader
configure:932: checking for working makeinfo
configure:955: checking for lyx
configure:1005: checking whether make sets ${MAKE}
configure:1043: checking for a BSD compatible install
configure:1098: checking for ranlib
configure:1128: checking for kpsewhich
configure:1166: checking for gcc
configure:1279: checking whether the C compiler (gcc  ) works
configure:1295: gcc -o conftestconftest.c  15
configure:1321: checking whether the C compiler (gcc  ) is a cross-compiler
configure:1326: checking whether we are using GNU C
configure:1335: gcc -E conftest.c
configure:1354: checking whether gcc accepts -g
configure:1388: checking for POSIXized ISC
configure:1409: checking how to run the C preprocessor
configure:1430: gcc -E  conftest.c /dev/null 2conftest.out
configure:1489: checking for AIX
configure:1514: checking for HP-UX
configure:1530: checking for SunOS 4.x
configure:1545: checking for SCO 3.2v4
configure:1571: checking for Cygwin environment
configure:1587: gcc -c -g -O2  conftest.c 15
configure: In function `main':
configure:1583: `__CYGWIN32__' undeclared (first use this function)
configure:1583: (Each undeclared identifier is reported only once
configure:1583: for each function it appears in.)
configure: failed program was:
#line 1576 "configure"
#include "confdefs.h"

int main() {

#ifndef __CYGWIN__
#define __CYGWIN__ __CYGWIN32__
#endif
return __CYGWIN__;
; return 0; }
configure:1604: checking for mingw32 environment
configure:1616: gcc -c -g -O2  conftest.c 15
configure: In function `main':
configure:1612: `__MINGW32__' undeclared (first use this function)
configure:1612: (Each undeclared identifier is reported only once
configure:1612: for each function it appears in.)
configure: failed program was:
#line 1609 "configure"
#include "confdefs.h"

int main() {
return __MINGW32__;
; return 0; }
configure:1635: checking for executable suffix
configure:1645: gcc -o conftest -g -O2   conftest.c  15
configure:1675: checking for a working C++ compiler
configure:1711: g++ -o conftestconftest.C  15
configure:1749: checking whether the C++ compiler (g++  ) is a cross-compiler
configure:1753: checking whether we are using GNU C++
configure:1762: g++ -E conftest.C
configure:1807: checking whether g++ accepts -g
configure:1845: checking how to run the C++ preprocessor
configure:1863: g++ -E  conftest.C /dev/null 2conftest.out
configure:1893: checking if C++ compiler supports mutable
configure:1909: g++ -c -O2  conftest.C 15
configure:1932: checking if C++ compiler supports partial specialization
configure:1950: g++ -c -O2  conftest.C 15
configure:1940: Internal compiler error.
configure:1940: Please submit a full bug report to `[EMAIL PROTECTED]'.
configure: failed program was:
#line 1934 "configure"
#include "confdefs.h"

templateclass T, class K
class k {   
public:
};
templateclass T class kvoid,T { };

int main() {

  kfloat, float b;
  kvoid,void a;

; return 0; }
configure:1972: checking whether the C++ compiler understands explicit
configure:1988: g++ -c -O2  conftest.C 15
configure:2010: checking for broken STL stack template
configure:2028: g++ -c -O2  conftest.C 15
configure:2018: parse error before `::'
/usr/include/g++/stack.h:29: `int' is not an aggregate type
/usr/include/g++/stack.h:29: confused by earlier errors, bailing out
configure: failed program was:
#line 2015 "configure"
#include "confdefs.h"

#include stack
using std::stack;

int main() {

stackint stakk;
stakk.push(0);

; return 0; }
configure:2051: checking whether the included std::string should be used
configure:2076: g++ -c -O2  conftest.C 15
configure:2064: parse error before `::'
configure: In function `int main()':
configure:2069: no member function `basic_stringchar,string_char_traitschar 
::clear()' defined
configure:2071: no member function `basic_stringchar,string_char_traitschar 
::erase()' defined
configure: failed program was:
#line 2061 "configure"
#include "confdefs.h"

#include string
using std::string;

int main() {

string a("hello there");
a.clear();
a = "hey";
 

Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)

[Jean-Marc Lasgouttes]

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

Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars  "Uwe" == Uwe Brauer [EMAIL PROTECTED] writes: | |
Lars Uwe While I had so far no problems in compiling LyX-1.0.3 I was
Lars faced | Uwe for 1.1.2 with a compiler problem, as is seems to
Lars me. I did not | Uwe try out 1.1.1. I have attached the error
Lars message and the | Uwe config.status. Thanks Uwe Brauer | | I
Lars would guess that you use gcc 2.7.x (try g++ -v to make sure).
Lars This | compiler is not able to compile lyx 1.1.x (will will
Lars maybe never be | able to).

Lars But why does it complain about ostream? the config log showed
Lars that ostream was not found, it seems it is used anyway...

Because configure should give an error when ostream has not been
found, telling that compilation will be impossible...

JMarc

Re: Have you just seen it ??

[Andre' Poenitz]

I tried it in wine but it does not even want to start.

*shrug*.

Andre'

--
André Pönitz . [EMAIL PROTECTED]

Re: Strange feature

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Jean-Marc" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| 
| Jean-Marc After debugging this a bit, it seems that you broke the
| Jean-Marc parsing of cdef files with the new regexp stuff. The
| Jean-Marc problem is that you do not handle backslash escapes, and
| Jean-Marc \\\"{o} is kept as is in chset map, instead of transforming
| Jean-Marc it to \"{o}.
| 
| Lars, I see that you  decided that escaping was bad and changed
| iso8859-1.cdef to reflect what you think is good. However, I see
| several problems:

The escaping was not just bad, it was plain wrong.
run lyx with -dbg key,keymap and you can see yourself.
Why demand escaping when it is not needed.

| - the concerns I have with the non robustness of your regexp-based
|   parser remain. I understand that regexps are fun, but...

if the line match it match, else it does not match. As for robustness,
it does not crash.

| - the other cdef files have not been modified, and thus the problem
|   remain for them

Note that the actual contents of the .cdef
files have not been used until I made my changes yesterday.

| - the current syntax does not make sense, since we have non-escaped "
|   characters inside "" groups.

So?
that matches ' "[^ ]" '

| - If you do not like those escape in the old files, we can in fact
|   just forget about the quotes and it should remove the need for
|   quoting (does it? if not this is a bug in lyxlex).

Yes that was one of my comments, why use two other chars as
delimiters.


| Why not just revert to the old parser?

Wrong use of lyxlex.
To use lyxlex as a glorified tokenizer is not right.

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| Michael "insetlatexaccent.C", line 645: Error:
| Michael InsetLatexAccent::ACCENT_TYPES is not accessible from file
| Michael level.
| 
| This one is strange, as Lars said.

We can move the enum into public space.

| Michael "lstrings.C", line 178: Error: Could not find a match for
| Michael std::count(const char*, const char*, const char).
| 
| Don't know about that.

it is a wrong count in the C++ lib,

the correct one is

templateclass InputIterator, class T
typename iterator_traitsInputIterator::difference_type
  count(InputIterator first, InputIterator last, const T
value);

when the one used in this case is:

template class _InputIter, class _Tp, class _Size
void count(_InputIter __first, _InputIter __last, const _Tp __value, _Size __n);

perhaps we should have a check in configure for this?

| Michael "lyxsum.C", line 119: Error: "," expected instead of "*".
| Michael "lyxsum.C", line 120: Error: fp is not defined.
| 
| Maybe removing 'register' would help. Lars, why is this code so
| complicated? 

Complicated? (it is one of the simplest files we have.)
Ok, it got a bit more complicated when I added a standard c++ way of
doing it instead of using stdio.
the fstream disted with gcc does not have the needed readsome method.

| Michael "layout.C", line 1217: Error: Cannot use std::pairbool, int
| Michael to initialize std::pairbool, unsigned. "layout.C", line
| Michael 1219: Error: Cannot use std::pairbool, int to initialize
| Michael std::pairbool, unsigned.
| 
| Don't know.

This constructor prototype is missing from the C++ lib:

  template class _U1, class _U2
  pair(const pair_U1, _U2 __p) : first(__p.first),
  second(__p.second) {}

but we should be able to make the types in the pair be the same.

| Michael "spellchecker.C", line 340: Error: Using static_cast to
| Michael convert from char*[14] to char*const* not allowed.
| 
| Don't know. Maybe a const_cast instead of a static_cast?

Yes, const_cast looks more correct.

Lgb

Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
| Lars  "Uwe" == Uwe Brauer [EMAIL PROTECTED] writes: | |
| Lars Uwe While I had so far no problems in compiling LyX-1.0.3 I was
| Lars faced | Uwe for 1.1.2 with a compiler problem, as is seems to
| Lars me. I did not | Uwe try out 1.1.1. I have attached the error
| Lars message and the | Uwe config.status. Thanks Uwe Brauer | | I
| Lars would guess that you use gcc 2.7.x (try g++ -v to make sure).
| Lars This | compiler is not able to compile lyx 1.1.x (will will
| Lars maybe never be | able to).
| 
| Lars But why does it complain about ostream? the config log showed
| Lars that ostream was not found, it seems it is used anyway...
| 
| Because configure should give an error when ostream has not been
| found, telling that compilation will be impossible...

I am speaking of the header.

If we want ostream:

#ifdef HAVE_OSTREAM
#include ostream
#else
#include iostream
#endif

The standard says that

typedef basic_ostreamchar ostream;

should be in ostream

but old implementations have it in iostream

Lgb

list off

[Mate Wierdl]

I just received the following message:


[1]  The electricity in the building (DUNN) will be off Dec 27-29 (M-W),
maybe even the 30th, but probably not.  Physical Plant is having to
change out major switch.

This means the users, devel and announce lists will be down for
this period.  Unfortunately, there is nothing I can do about this.
There may be a possibilty to move the lists temporarily to another
machine, but that seems to be more trouble than it is worth (visualize
changing DNS entries and list manager config files  and friends).

While I will be in Hungary from Dec 19-Jan 7, I will try to make sure
that apart from the above dates, all will be functional.

Mate

Re: figure-floats broken inside {multicols}

[Phil Nitschke]

 "JMarc" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 "Phil" == Phil Nitschke [EMAIL PROTECTED] writes:

  Phil Figure floats go missing from my postscript output whenever I
  Phil add them to text inside of the latex multicols \begin..\end
  Phil region.

  Phil Non-floating figures are OK within multicols text.

  JMarc The abstract of the version of multicol I have here says:

  JMarc %   This article describes the use and the implementation of the \mc{}
  JMarc %   environment. This environment allows switching between
  JMarc %   one and multicolumn format on the same page. Footnotes are handled
  JMarc %   correctly (for the most part), but will be placed at the bottom of
  JMarc %   the page and not under each column.  \LaTeX{}'s float mechanism,
  JMarc %   however, is partly disabled in the current implementation.  At the
  JMarc %   moment only page-wide floats (i.e., star-forms) can be used within
  JMarc %   the scope of the environment.

  JMarc It seems that the last sentence is the answer to your question.

Thanks for getting back to me.  I did not go so far as to read the
latex files, so I did not find this information.

Perhaps a note could be added to the documentation (extended features,
section 4.2), to avoid other people getting frustrated by unexplained
behaviour?

Anyway, I appreciate you taking the time to look at this.  Thank you.

-- 
Phil

Re: FILE - ostream

[Arnd Hanses]

On 17 Dec 1999 10:26:31 +0100, Jean-Marc Lasgouttes wrote:

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

Asger But then, even that is hard to find these days. So many other
Asger things come first. For instance, I'll going to drik a few
Asger beers tomorrow.

Do you mean that you need to prepare yourself so long in advance
everytime you go drink a few beers? I understand why you are a busy
man... 

JMarc

Jean-Marc obviously underestimated the cultural difference :-) Did you
really never try to go to drink a beer (öl) in northern Norway? You'd
need weeks of complicated preparations. Denmark has already developed a
certain degree of indulgency in this respect

Arnd

Re: FILE - ostream

[Lars Gullik Bjønnes]

"Arnd Hanses" [EMAIL PROTECTED] writes:

| Jean-Marc obviously underestimated the cultural difference :-) Did you
| really never try to go to drink a beer (öl) in northern Norway?

ØL! (öl is swedish)

since I live in the south or Norway I drink beer the same was as Asger
does.

Lgb

Re: multibyte support for lyx

[ChangGil Han]

Sure, you can.

Re: Internalization

[Shigeru Miyata]

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

  As there're a significant number of LyX users under Windows, some of
 them might want to contribute to the translation too.  Imagine the trouble
 they would encounter when some of them edit the translation file under Unix
 while others under Windows.  A little carelessness on encoding will mess up
 the whole translation file which is very big file.  Luckily, CVS might help
 them to save some of their work, but certainly not all.

There are different po files for different encodings.  This kind of mess
up
is very unlikely to occur.  What we have to be careful is that these
files
must be in sync.  So contributer is recommended to use encoding
converters
to update all the po files in the same language as the one s/he updates.
Since this is a devel list, may I speak a little bit more technically
oriented thing here?  libgettext (not only GNU version) are locale
based.
And XInputMethod/XOutputMethod are locale based.  Hence, with the
current
structure of LyX, menu/message strings and document languages must be in
the same encoding.  (NB ISO8859-1 encoding are used in multiple
languages.)
Of course this is really easy to be "fixed" if you want.  You have only
to
write a class to manage environment variable "LANG".  But I suspect Lars
wants to the C++ locale when it is more widely available, rather than
hack
the C locale.

  By "superset of 7bit ASCII", do you mean that every byte is 7 bit?  If
 yes, UTF-7 should be used instead.  On the other hand, Big5 couldn't be used
 because the encoding is 8 bit based.

Big5 is a superset of 7bit ASCII in the sense that every 7bit character
in
the neutral shift state is treated as 7bit ASCII.  Every multibyte
character
starts with a byte with the 8 bit flag on (which shift the state of the
succeeding one byte).  GNU gettext can handle Big5 just fine.

Regards,
SMiyata

Re: [Fwd: multibyte support for lyx]

[Shigeru Miyata]

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

   That's a good news.  However, sorry that I sound skeptical, but Shigeru
  in another post said that Xform cannot draw 16 bit character strings.
  You've fiddled Xform?

We draw strings ourselves in the main buffer of LyX.  While menues and
dialogs
are drawn by Xforms.  You can't show internationlized
Chinese/Japanese/Korean
strings in the menues, nor in Warning messages, TOC etc.  Nor can you
Search/Replace multibyte strings easily (hard to input, can't display).
We have to wait GUI indep for these to be displayed correctly.

Regards,
SMiyata

Re: Hebrew support for LyX

[Shigeru Miyata]

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

  TTB_RTL (for Chinese, Japanese, etc.) and TTB_LTR (for Mongolian)
  primitives.
 
  Actually, there's another possible solution (or even simpler): rotate all
 characters to the left by 90:-)  but only if it's supported by LaTeX.  If this is
 supported, we just need to type in LTR then TTB and after rotation, the text will be
 TTB then RTL.

LaTeX need not support this at all.  You have only to use the rotated
fonts.
CJKvert.sty is designed to use this.

  But I'm not sure if LaTeX supports already double-byte encoding, so I'm not
 going to ask this question in the newsgroup for the moment.

There are essentially two ways to support double-byte encodings.  One is
to
use special TeX compilers whose internal string representation is 16
bit.
These compilers have "Translation Process" for reading byte streams of
input
files so that the TeX proper will receive wide character string instead
of
byte streams.  pTeX can read Japanese multibyte encodings, hTeX can read
Korean, and omega can read anything as far as you have an appropriate
.ocp
(Omega Compiled translation Process:  There already is a Big5 .ocp but
no
one has written Japanese/Korean .ocp yet).
The other way is to use the catcode magic.  If you set the multibyte
system
leading bytes as active characters, then TeX considers each multibyte
character a command macro which selects a character in a font (256
each).
So then, if you have divided multibyte character fonts into smaller
pieces
beforehand, the ordinary TeX can process multibyte encoded source files.
This approach is taken by the CJK macro package.  You are more likely to
see the TeX stack exhausted errors, though.

Regards,
SMiyata

Re: Internalization

[Seak, Teng-Fong]

Shigeru Miyata 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.

 Yup, I know that.  I just mentioned Unicode because I wanted to
high-light its usage. :-)

> > So I suppose characters (eg in menus) are displayed using Unicode.
>
> What gain do we have?

 For LyX, Latin-1 languages and maybe even 8 bit encoded languages, I'm
afraid the gain is quite small.  One obvious advantage is that there's no
need to translate menu/message strings to Unicode from their "original"
encoding.  But for other language, the benefit should be greater.  In
traditional Chinese, Big5 isn't the unique encoding: there're EUC-TW and
XCN-11643-x and some extension created to suit daily usage in HK.  In one
word, it's a mess.  I don't know much about Japanese, but I know that
there're JIS, EUC-JP and Shift JIS.  It seems that one of them is used in
Windows while another one is for Unix/X, right?  Auto JIS is the automatic
recognition, right?  Could it do the job flawlessly?  Don't you find it
frustrated to have so many different encodings?  The same exists for other
languages like Greek and Russian in which one encoding is for Unix/X and the
other is for Windows.

 As there're a significant number of LyX users under Windows, some of
them might want to contribute to the translation too.  Imagine the trouble
they would encounter when some of them edit the translation file under Unix
while others under Windows.  A little carelessness on encoding will mess up
the whole translation file which is very big file.  Luckily, CVS might help
them to save some of their work, but certainly not all.

> > 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.

 I was talking about menu/message strings encoding.  So there shouldn't
be any problem because we can't cut and paste a menu item :-)

 For document encoding, you're surely correct.  Take Linux as example,
isn't it that the conversion is done by the kernel?  It seems to be so at
least for consoles since kernel uses Unicode internally.

> >   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...)

 By "superset of 7bit ASCII", do you mean that every byte is 7 bit?  If
yes, UTF-7 should be used instead.  On the other hand, Big5 couldn't be used
because the encoding is 8 bit based.

> However, FYI, XForms cannot draw 16 bit character strings.

 I just remembered that in CLE (Chinese Linux Externsion) package, they
manage to display Chinese in LyX.  Or is it KLyX?

 Seak

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Jean-Marc Lasgouttes]

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

Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I
Lars> already answered him to add a #include "support/LOstream.h" at
Lars> the | beginning of debug.h. I think he is using STL string, and
Lars> ostreams | are defined in lyxstring.h, so I did not see that I
Lars> missed the header | in my last debug patch.

Lars> I think iostream is required to includ ostream so I think
Lars> LOstream.h is a bit wrong.

This error occurs _before_ DebugStream.h is included, so iostream has
not been read yet at this point. Have a look at debug.h and you'll see
what I mean (the two static members I added to Debug).

Lars> I had some problems with L[IO]stream.h when trying out the gcu
Lars> libstd++ libarary.

What kind of problems?

JMarc

lyx-1.1.2, problems under SuSe 5.3 (libc5)

[Uwe Brauer]

Hello

While I had so far no problems in compiling LyX-1.0.3
I was faced for 1.1.2 with a compiler problem, as is seems to me. I did 
not try out 1.1.1. I have attached the error message and the
config.status. 
Thanks
Uwe Brauer


This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:630: checking host system type
configure:651: checking target system type
configure:669: checking build system type
configure:694: checking config.cache system type
configure:723: checking for a BSD compatible install
configure:776: checking whether build environment is sane
configure:833: checking whether make sets ${MAKE}
configure:880: checking for working aclocal
configure:893: checking for working autoconf
configure:906: checking for working automake
configure:919: checking for working autoheader
configure:932: checking for working makeinfo
configure:955: checking for lyx
configure:1005: checking whether make sets ${MAKE}
configure:1043: checking for a BSD compatible install
configure:1098: checking for ranlib
configure:1128: checking for kpsewhich
configure:1166: checking for gcc
configure:1279: checking whether the C compiler (gcc  ) works
configure:1295: gcc -o conftestconftest.c  1>&5
configure:1321: checking whether the C compiler (gcc  ) is a cross-compiler
configure:1326: checking whether we are using GNU C
configure:1335: gcc -E conftest.c
configure:1354: checking whether gcc accepts -g
configure:1388: checking for POSIXized ISC
configure:1409: checking how to run the C preprocessor
configure:1430: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:1489: checking for AIX
configure:1514: checking for HP-UX
configure:1530: checking for SunOS 4.x
configure:1545: checking for SCO 3.2v4
configure:1571: checking for Cygwin environment
configure:1587: gcc -c -g -O2  conftest.c 1>&5
configure: In function `main':
configure:1583: `__CYGWIN32__' undeclared (first use this function)
configure:1583: (Each undeclared identifier is reported only once
configure:1583: for each function it appears in.)
configure: failed program was:
#line 1576 "configure"
#include "confdefs.h"

int main() {

#ifndef __CYGWIN__
#define __CYGWIN__ __CYGWIN32__
#endif
return __CYGWIN__;
; return 0; }
configure:1604: checking for mingw32 environment
configure:1616: gcc -c -g -O2  conftest.c 1>&5
configure: In function `main':
configure:1612: `__MINGW32__' undeclared (first use this function)
configure:1612: (Each undeclared identifier is reported only once
configure:1612: for each function it appears in.)
configure: failed program was:
#line 1609 "configure"
#include "confdefs.h"

int main() {
return __MINGW32__;
; return 0; }
configure:1635: checking for executable suffix
configure:1645: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1675: checking for a working C++ compiler
configure:1711: g++ -o conftestconftest.C  1>&5
configure:1749: checking whether the C++ compiler (g++  ) is a cross-compiler
configure:1753: checking whether we are using GNU C++
configure:1762: g++ -E conftest.C
configure:1807: checking whether g++ accepts -g
configure:1845: checking how to run the C++ preprocessor
configure:1863: g++ -E  conftest.C >/dev/null 2>conftest.out
configure:1893: checking if C++ compiler supports mutable
configure:1909: g++ -c -O2  conftest.C 1>&5
configure:1932: checking if C++ compiler supports partial specialization
configure:1950: g++ -c -O2  conftest.C 1>&5
configure:1940: Internal compiler error.
configure:1940: Please submit a full bug report to `[EMAIL PROTECTED]'.
configure: failed program was:
#line 1934 "configure"
#include "confdefs.h"

template
class k {   
public:
};
template class k { };

int main() {

  k b;
  k a;

; return 0; }
configure:1972: checking whether the C++ compiler understands explicit
configure:1988: g++ -c -O2  conftest.C 1>&5
configure:2010: checking for broken STL stack template
configure:2028: g++ -c -O2  conftest.C 1>&5
configure:2018: parse error before `::'
/usr/include/g++/stack.h:29: `int' is not an aggregate type
/usr/include/g++/stack.h:29: confused by earlier errors, bailing out
configure: failed program was:
#line 2015 "configure"
#include "confdefs.h"

#include 
using std::stack;

int main() {

stack stakk;
stakk.push(0);

; return 0; }
configure:2051: checking whether the included std::string should be used
configure:2076: g++ -c -O2  conftest.C 1>&5
configure:2064: parse error before `::'
configure: In function `int main()':
configure:2069: no member function `basic_string::clear()' defined
configure:2071: no member function `basic_string::erase()' defined
configure: failed program was:
#line 2061 "configure"
#include "confdefs.h"

#include 
using std::string;

int main() {

string a("hello there");
a.clear();
a = "hey";

Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)

[Jean-Marc Lasgouttes]

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

Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> > "Uwe" == Uwe Brauer <[EMAIL PROTECTED]> writes: | |
Lars> Uwe> While I had so far no problems in compiling LyX-1.0.3 I was
Lars> faced | Uwe> for 1.1.2 with a compiler problem, as is seems to
Lars> me. I did not | Uwe> try out 1.1.1. I have attached the error
Lars> message and the | Uwe> config.status. Thanks Uwe Brauer | | I
Lars> would guess that you use gcc 2.7.x (try g++ -v to make sure).
Lars> This | compiler is not able to compile lyx 1.1.x (will will
Lars> maybe never be | able to).

Lars> But why does it complain about ostream? the config log showed
Lars> that ostream was not found, it seems it is used anyway...

Because configure should give an error when ostream has not been
found, telling that compilation will be impossible...

JMarc

Re: Have you just seen it ??

[Andre' Poenitz]

I tried it in wine but it does not even want to start.

*shrug*.

Andre'

--
André Pönitz . [EMAIL PROTECTED]

Re: Strange "feature"

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| 
| Jean-Marc> After debugging this a bit, it seems that you broke the
| Jean-Marc> parsing of cdef files with the new regexp stuff. The
| Jean-Marc> problem is that you do not handle backslash escapes, and
| Jean-Marc> \\\"{o} is kept as is in chset map, instead of transforming
| Jean-Marc> it to \"{o}.
| 
| Lars, I see that you  decided that escaping was bad and changed
| iso8859-1.cdef to reflect what you think is good. However, I see
| several problems:

The escaping was not just bad, it was plain wrong.
run lyx with -dbg key,keymap and you can see yourself.
Why demand escaping when it is not needed.

| - the concerns I have with the non robustness of your regexp-based
|   parser remain. I understand that regexps are fun, but...

if the line match it match, else it does not match. As for robustness,
it does not crash.

| - the other cdef files have not been modified, and thus the problem
|   remain for them

Note that the actual contents of the .cdef
files have not been used until I made my changes yesterday.

| - the current syntax does not make sense, since we have non-escaped "
|   characters inside "" groups.

So?
that matches ' "[^ ]" '

| - If you do not like those escape in the old files, we can in fact
|   just forget about the quotes and it should remove the need for
|   quoting (does it? if not this is a bug in lyxlex).

Yes that was one of my comments, why use two other chars as
delimiters.


| Why not just revert to the old parser?

Wrong use of lyxlex.
To use lyxlex as a glorified tokenizer is not right.

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| Michael> "insetlatexaccent.C", line 645: Error:
| Michael> InsetLatexAccent::ACCENT_TYPES is not accessible from file
| Michael> level.
| 
| This one is strange, as Lars said.

We can move the enum into public space.

| Michael> "lstrings.C", line 178: Error: Could not find a match for
| Michael> std::count<>(const char*, const char*, const char).
| 
| Don't know about that.

it is a wrong count in the C++ lib,

the correct one is

template
typename iterator_traits::difference_type
  count(InputIterator first, InputIterator last, const T&
value);

when the one used in this case is:

template 
void count(_InputIter __first, _InputIter __last, const _Tp& __value, _Size& __n);

perhaps we should have a check in configure for this?

| Michael> "lyxsum.C", line 119: Error: "," expected instead of "*".
| Michael> "lyxsum.C", line 120: Error: fp is not defined.
| 
| Maybe removing 'register' would help. Lars, why is this code so
| complicated? 

Complicated? (it is one of the simplest files we have.)
Ok, it got a bit more complicated when I added a standard c++ way of
doing it instead of using stdio.
the fstream disted with gcc does not have the needed readsome method.

| Michael> "layout.C", line 1217: Error: Cannot use std::pair
| Michael> to initialize std::pair. "layout.C", line
| Michael> 1219: Error: Cannot use std::pair to initialize
| Michael> std::pair.
| 
| Don't know.

This constructor prototype is missing from the C++ lib:

  template 
  pair(const pair<_U1, _U2>& __p) : first(__p.first),
  second(__p.second) {}

but we should be able to make the types in the pair be the same.

| Michael> "spellchecker.C", line 340: Error: Using static_cast to
| Michael> convert from char*[14] to char*const* not allowed.
| 
| Don't know. Maybe a const_cast instead of a static_cast?

Yes, const_cast looks more correct.

Lgb

Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> > "Uwe" == Uwe Brauer <[EMAIL PROTECTED]> writes: | |
| Lars> Uwe> While I had so far no problems in compiling LyX-1.0.3 I was
| Lars> faced | Uwe> for 1.1.2 with a compiler problem, as is seems to
| Lars> me. I did not | Uwe> try out 1.1.1. I have attached the error
| Lars> message and the | Uwe> config.status. Thanks Uwe Brauer | | I
| Lars> would guess that you use gcc 2.7.x (try g++ -v to make sure).
| Lars> This | compiler is not able to compile lyx 1.1.x (will will
| Lars> maybe never be | able to).
| 
| Lars> But why does it complain about ostream? the config log showed
| Lars> that ostream was not found, it seems it is used anyway...
| 
| Because configure should give an error when ostream has not been
| found, telling that compilation will be impossible...

I am speaking of the header.

If we want ostream:

#ifdef HAVE_OSTREAM
#include 
#else
#include 
#endif

The standard says that

typedef basic_ostream ostream;

should be in 

but old implementations have it in 

Lgb

list off

[Mate Wierdl]

I just received the following message:


[1]  The electricity in the building (DUNN) will be off Dec 27-29 (M-W),
maybe even the 30th, but probably not.  Physical Plant is having to
change out major switch.

This means the users, devel and announce lists will be down for
this period.  Unfortunately, there is nothing I can do about this.
There may be a possibilty to move the lists temporarily to another
machine, but that seems to be more trouble than it is worth (visualize
changing DNS entries and list manager config files  and friends).

While I will be in Hungary from Dec 19-Jan 7, I will try to make sure
that apart from the above dates, all will be functional.

Mate

Re: figure-floats broken inside {multicols}

[Phil Nitschke]

> "JMarc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Phil" == Phil Nitschke <[EMAIL PROTECTED]> writes:

  Phil> Figure floats go missing from my postscript output whenever I
  Phil> add them to text inside of the latex multicols \begin..\end
  Phil> region.

  Phil> Non-floating figures are OK within multicols text.

  JMarc> The abstract of the version of multicol I have here says:

  JMarc> %   This article describes the use and the implementation of the \mc{}
  JMarc> %   environment. This environment allows switching between
  JMarc> %   one and multicolumn format on the same page. Footnotes are handled
  JMarc> %   correctly (for the most part), but will be placed at the bottom of
  JMarc> %   the page and not under each column.  \LaTeX{}'s float mechanism,
  JMarc> %   however, is partly disabled in the current implementation.  At the
  JMarc> %   moment only page-wide floats (i.e., star-forms) can be used within
  JMarc> %   the scope of the environment.

  JMarc> It seems that the last sentence is the answer to your question.

Thanks for getting back to me.  I did not go so far as to read the
latex files, so I did not find this information.

Perhaps a note could be added to the documentation (extended features,
section 4.2), to avoid other people getting frustrated by unexplained
behaviour?

Anyway, I appreciate you taking the time to look at this.  Thank you.

-- 
Phil

Re: FILE -> ostream

[Arnd Hanses]

On 17 Dec 1999 10:26:31 +0100, Jean-Marc Lasgouttes wrote:

>> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>
>Asger> But then, even that is hard to find these days. So many other
>Asger> things come first. For instance, I'll going to drik a few
>Asger> beers tomorrow.
>
>Do you mean that you need to prepare yourself so long in advance
>everytime you go drink a few beers? I understand why you are a busy
>man... 
>
>JMarc

Jean-Marc obviously underestimated the cultural difference :-) Did you
really never try to go to drink a beer (öl) in northern Norway? You'd
need weeks of complicated preparations. Denmark has already developed a
certain degree of indulgency in this respect

Arnd

Re: FILE -> ostream

[Lars Gullik Bjønnes]

"Arnd Hanses" <[EMAIL PROTECTED]> writes:

| Jean-Marc obviously underestimated the cultural difference :-) Did you
| really never try to go to drink a beer (öl) in northern Norway?

ØL! (öl is swedish)

since I live in the south or Norway I drink beer the same was as Asger
does.

Lgb

Re: multibyte support for lyx

[ChangGil Han]

Sure, you can.

Re: Internalization

[Shigeru Miyata]

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

>  As there're a significant number of LyX users under Windows, some of
> them might want to contribute to the translation too.  Imagine the trouble
> they would encounter when some of them edit the translation file under Unix
> while others under Windows.  A little carelessness on encoding will mess up
> the whole translation file which is very big file.  Luckily, CVS might help
> them to save some of their work, but certainly not all.

There are different po files for different encodings.  This kind of mess
up
is very unlikely to occur.  What we have to be careful is that these
files
must be in sync.  So contributer is recommended to use encoding
converters
to update all the po files in the same language as the one s/he updates.
Since this is a devel list, may I speak a little bit more technically
oriented thing here?  libgettext (not only GNU version) are locale
based.
And XInputMethod/XOutputMethod are locale based.  Hence, with the
current
structure of LyX, menu/message strings and document languages must be in
the same encoding.  (NB ISO8859-1 encoding are used in multiple
languages.)
Of course this is really easy to be "fixed" if you want.  You have only
to
write a class to manage environment variable "LANG".  But I suspect Lars
wants to the C++ locale when it is more widely available, rather than
hack
the C locale.

>  By "superset of 7bit ASCII", do you mean that every byte is 7 bit?  If
> yes, UTF-7 should be used instead.  On the other hand, Big5 couldn't be used
> because the encoding is 8 bit based.

Big5 is a superset of 7bit ASCII in the sense that every 7bit character
in
the neutral shift state is treated as 7bit ASCII.  Every multibyte
character
starts with a byte with the 8 bit flag on (which shift the state of the
succeeding one byte).  GNU gettext can handle Big5 just fine.

Regards,
SMiyata

Re: [Fwd: multibyte support for lyx]

[Shigeru Miyata]

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

> >  That's a good news.  However, sorry that I sound skeptical, but Shigeru
> > in another post said that Xform cannot draw 16 bit character strings.
> > You've fiddled Xform?

We draw strings ourselves in the main buffer of LyX.  While menues and
dialogs
are drawn by Xforms.  You can't show internationlized
Chinese/Japanese/Korean
strings in the menues, nor in Warning messages, TOC etc.  Nor can you
Search/Replace multibyte strings easily (hard to input, can't display).
We have to wait GUI indep for these to be displayed correctly.

Regards,
SMiyata

Re: Hebrew support for LyX

[Shigeru Miyata]

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

> > TTB_RTL (for Chinese, Japanese, etc.) and TTB_LTR (for Mongolian)
> > primitives.
> 
>  Actually, there's another possible solution (or even simpler): rotate all
> characters to the left by 90:-)  but only if it's supported by LaTeX.  If this is
> supported, we just need to type in LTR then TTB and after rotation, the text will be
> TTB then RTL.

LaTeX need not support this at all.  You have only to use the rotated
fonts.
CJKvert.sty is designed to use this.

>  But I'm not sure if LaTeX supports already double-byte encoding, so I'm not
> going to ask this question in the newsgroup for the moment.

There are essentially two ways to support double-byte encodings.  One is
to
use special TeX compilers whose internal string representation is 16
bit.
These compilers have "Translation Process" for reading byte streams of
input
files so that the TeX proper will receive wide character string instead
of
byte streams.  pTeX can read Japanese multibyte encodings, hTeX can read
Korean, and omega can read anything as far as you have an appropriate
.ocp
(Omega Compiled translation Process:  There already is a Big5 .ocp but
no
one has written Japanese/Korean .ocp yet).
The other way is to use the catcode magic.  If you set the multibyte
system
leading bytes as active characters, then TeX considers each multibyte
character a command macro which selects a character in a font (256
each).
So then, if you have divided multibyte character fonts into smaller
pieces
beforehand, the ordinary TeX can process multibyte encoded source files.
This approach is taken by the CJK macro package.  You are more likely to
see the TeX stack exhausted errors, though.

Regards,
SMiyata