Georg Baum <[EMAIL PROTECTED]> writes:
| Am Sonntag, 20. August 2006 23:21 schrieb Lars Gullik Bjønnes:
| > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >
| > | This also seems to be relevant to some of our problems. Lars?
| > |
|
http://sourceforge.net/tracker/index.php?func=detail&aid=1
Georg Baum <[EMAIL PROTECTED]> writes:
> > Could you please tell a naive guy why we have to care about different
> > unicode encodings internally?
> > I would have assumed that we use UTF-8 in files and ucs4 in memory.
> > What's the problem?
> Mainly that not all has been converted yet. Some s
TechTonics wrote:
> This trick works with windows as well as linux, and of course such
> scripts could be distributed with lyx.
BO: Are you sure about this part? This is not as simple as a script,
we need pdfopen.exe, pdfclose.exe to track the process id of acrobat
reader and re-open it if nec
Am Montag, 21. August 2006 21:44 schrieb Michael Gerz:
> Lars Gullik Bjønnes schrieb:
> > Yes... I think so to, but there _might_ be some utf8...
> >
> Could you please tell a naive guy why we have to care about different
> unicode encodings internally?
>
> I would have assumed that we use UTF
Lars Gullik Bjønnes schrieb:
| I think we have no choice but use ucs4/docstring for all strings that can
| contain unicode internally.
Yes... I think so to, but there _might_ be some utf8...
Could you please tell a naive guy why we have to care about different
unicode encodings internally?
Am Montag, 21. August 2006 18:26 schrieb Lars Gullik Bjønnes:
> What is a scrollbar thum?
The slider.
Georg
Am Montag, 21. August 2006 00:04 schrieb Lars Gullik Bjønnes:
> - All output:
> - text (perhaps finished?)
> - latex (oh... can of worms)
> - docbook
> - Perhaps reading of layout files, ui files etc. (I think that
> we can skip tese. l10n of these should be done through t
Am Sonntag, 20. August 2006 23:21 schrieb Lars Gullik Bjønnes:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | This also seems to be relevant to some of our problems. Lars?
> |
http://sourceforge.net/tracker/index.php?func=detail&aid=1391875&group_id=7586&atid=107586
>
> I am not sure..
Several people have mentioned that there is no acrobat reader for
x86-64 systems. This is not the case. The acrobat reader rpm works
just fine. Maybe it is not in 64 bit, but it runs well.
Bo
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> UTF-8 is chars so BOM has no place there...
Right. I see that now, but it was the act of (trying to) explain that revealed
to me that I actually didn't understand things after all. I now understand
that Windows file formats tend to output directl
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
| > I installed qt4 in order to check whether it is as fast as Abdel
| > claims it is. I am the only one finding that moving around the
| > scrollbar thumb is much smoother with gtk?
|
| Ah bu
Georg Baum <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
|
| > Georg Baum wrote:
| >> No. And AFAIK Abdel never claimed that qt4 was fast on linux. Moving the
| >> scrollbar thumb of the userguide takes several (more than 5) seconds for
| >> me until it moves with qt4. with gtk there is
Edwin Leuven wrote:
Abdelrazak Younes wrote:
The changes look good but is this a cleanup or a bug fix? I don't see
all toobar buttons and menu items as checkable here...
there is a checkable "compressed" menu item iirc...
Yes and the Change Tracking one and they both work correctly I think.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| Abdelrazak> Jean-Marc Lasgouttes wrote:
| >> I installed qt4 in order to check whether it is as fast as Abdel
| >> claims it is. I am the only one finding that moving around
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
| > I installed qt4 in order to check whether it is as fast as Abdel
| > claims it is. I am the only one finding that moving around the
| > scrollbar thumb is much smoother with gtk?
|
| Ah but that's before unicode. Ever
Abdelrazak Younes wrote:
The changes look good but is this a cleanup or a bug fix? I don't see
all toobar buttons and menu items as checkable here...
there is a checkable "compressed" menu item iirc...
Georg Baum wrote:
Abdelrazak Younes wrote:
Hum, one question about gtk: if you drag the scrollbar slider is the
workarea updated with the slider position or only if you release the
slider?
It is updated with the slider position.
too bad :-/
Abdel.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars> svn delete svn copy
| Lars>
|
| What version is the boost in trunk? Can there be problems wrt
| exceptions?
1.33.1/1.33.2
No, we have not changeed our boost wrt that.
--
Lgb
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
This patch tries to sanitize a bit the way menus are generated on
qt4. Actions are not made checkable for no reason, and the code to
set action features is moved to
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> No. And AFAIK Abdel never claimed that qt4 was fast on linux. Moving the
>> scrollbar thumb of the userguide takes several (more than 5) seconds for
>> me until it moves with qt4. with gtk there is only a little delay (less
>> than one second). That
Angus Leeming <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| >> Can you try to change the utf-8 to ucs-4 conversion to use either
| >> "UCS-4BE" or "UCS-4LE", instead of "UCS-4"? Also the conversion the
| >> other way ucs-4 -> ucs-2, try with UCS-2BE and UCS-2LE.
|
Abdelrazak Younes wrote:
> Hum, one question about gtk: if you drag the scrollbar slider is the
> workarea updated with the slider position or only if you release the
> slider?
It is updated with the slider position.
Georg
Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
I installed qt4 in order to check whether it is as fast as Abdel
claims it is. I am the only one finding that moving around the
scrollbar thumb is much smoother with gtk?
No. And AFAIK Abdel never claimed that qt4 was fast on linux. Moving the
scr
Jean-Marc Lasgouttes wrote:
I installed qt4 in order to check whether it is as fast as Abdel
claims it is. I am the only one finding that moving around the
scrollbar thumb is much smoother with gtk?
Hum, one question about gtk: if you drag the scrollbar slider is the
workarea updated with the
Jean-Marc Lasgouttes wrote:
[This is with or without my previous menu patch]
- run LyX
- Help>Introduction
- Help>Tutorial
- View>Intro.lyx
- exit
===> crash!
I don't see that... Are you sure your patch is not applied?
Abdel.
Georg Baum wrote:
Abdelrazak Younes wrote:
Well, the reference labels (and cross-reference) are part of the lyx
format aren't they?
They are. And that is the proof that you now have the ucs4 conversion
machinery working: The labels are currently not stored in docstring, but in
std::string as
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
>> This patch tries to sanitize a bit the way menus are generated on
>> qt4. Actions are not made checkable for no reason, and the code to
>> set action features is moved to Action::update.
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc Lasgouttes wrote:
>> I installed qt4 in order to check whether it is as fast as Abdel
>> claims it is. I am the only one finding that moving around the
>> scrollbar thumb is much smoother with gtk?
Georg> No. And AFAIK Abdel
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
>> I installed qt4 in order to check whether it is as fast as Abdel
>> claims it is. I am the only one finding that moving around the
>> scrollbar thumb is much smoother with gtk?
Abdelraza
Jean-Marc Lasgouttes wrote:
This patch tries to sanitize a bit the way menus are generated on qt4.
Actions are not made checkable for no reason, and the code to set
action features is moved to Action::update.
I am impressed!
Welcome Jean-Marc :-)
Abdel.
Jean-Marc Lasgouttes wrote:
> I installed qt4 in order to check whether it is as fast as Abdel
> claims it is. I am the only one finding that moving around the
> scrollbar thumb is much smoother with gtk?
No. And AFAIK Abdel never claimed that qt4 was fast on linux. Moving the
scrollbar thumb of
Jean-Marc Lasgouttes wrote:
I installed qt4 in order to check whether it is as fast as Abdel
claims it is. I am the only one finding that moving around the
scrollbar thumb is much smoother with gtk?
Ah but that's before unicode. Everything is very slow since that was
merged... including scroll
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> This patch makes the pkg-config based detection of Qt4 honor
>> --with-qt4-dir:
Angus> Is the oprofile FATAL=0 comment and option still needed? John
Angus> had this for the Qt3 fr
Edwin Leuven <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > There is a conversion method:
| > std::vector QVector::toStdVector () const
|
| i think this one is only available if qt is compiled with stl
| compatibility
|
| the attached works for me
| Index: src/frontends/qt4/QLIma
Abdelrazak Younes wrote:
> Well, the reference labels (and cross-reference) are part of the lyx
> format aren't they?
They are. And that is the proof that you now have the ucs4 conversion
machinery working: The labels are currently not stored in docstring, but in
std::string as read in from the f
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> This patch makes the pkg-config based detection of Qt4 honor
> --with-qt4-dir:
Is the oprofile FATAL=0 comment and option still needed? John had this for the
Qt3 frontend.
Angus
[This is with or without my previous menu patch]
- run LyX
- Help>Introduction
- Help>Tutorial
- View>Intro.lyx
- exit
===> crash!
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1221143904 (LWP 17220)]
0x081b3127 in LyXFunc::getStatus (this=0x898a808, [EMAIL PROTECTE
I installed qt4 in order to check whether it is as fast as Abdel
claims it is. I am the only one finding that moving around the
scrollbar thumb is much smoother with gtk?
JMarc
Helge Hafting wrote:
> I thought UTF-8 didn't care about endianness, being a single-byte
> encoding?
That would be great: stuffing the whole unicode range in a single-byte
encoding, but for obvious reasons that does not work.
You are right that the endianness is not a problem in utf8, since it d
Helge Hafting wrote:
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Can you try to change the utf-8 to ucs-4 conversion to use either
"UCS-4BE" or "UCS-4LE", instead of "UCS-4"? Also the conversion the
other way ucs-4 -> ucs-2, try with UCS-2BE and UCS-2LE.
And
This patch tries to sanitize a bit the way menus are generated on qt4.
Actions are not made checkable for no reason, and the code to set
action features is moved to Action::update.
JMarc
Index: src/frontends/qt4/Action.C
===
--- src
This patch makes the pkg-config based detection of Qt4 honor
--with-qt4-dir:
* add $qt4_cv_dir/lib to pkg-config search path
* add $qt4_cv_dir/bin to moc search path (and use AC_PATH_PROGS in
order to get full path to moc).
This changes make configuration easier for the poor souls who already
had
Helge Hafting <[EMAIL PROTECTED]> writes:
> I thought UTF-8 didn't care about endianness, being a single-byte
> encoding? A conversion to UCS-4 can go wrong if he convert
> to the wrong UCS-4 format, but utf-8 is supposed to be
> the same no matter what endianness the machine uses?
Sigh. Yes, you
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Can you try to change the utf-8 to ucs-4 conversion to use either
"UCS-4BE" or "UCS-4LE", instead of "UCS-4"? Also the conversion the
other way ucs-4 -> ucs-2, try with UCS-2BE and UCS-2LE.
And with the attached patch where I h
This trick works with windows as well as linux, and of course such scripts
could be distributed with lyx.
Are you sure about this part? This is not as simple as a script, we
need pdfopen.exe, pdfclose.exe to track the process id of acrobat
reader and re-open it if necessary. I seriously doubt th
The menu item is always functional.
It always updates the dvi/pdf/ps/whatever file - so it works.
Click on the file in your favourite file manager - you'll
see the new content.
The file is indeed always updated, but do we expect a user to dig
through the complicated tmp directory structure to vi
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Can you try to change the utf-8 to ucs-4 conversion to use either
"UCS-4BE" or "UCS-4LE", instead of "UCS-4"? Also the conversion the
other way ucs-4 -> ucs-2, try with UCS-2BE and UCS-2LE.
And with the attached pa
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Can you try to change the utf-8 to ucs-4 conversion to use either
>> "UCS-4BE" or "UCS-4LE", instead of "UCS-4"? Also the conversion the
>> other way ucs-4 -> ucs-2, try with UCS-2BE and UCS-2LE.
> And with the attached patch where I have put LE eve
Hossein Noorikhah wrote:
Hi.
Has anyone applied the patch on SVN? I'm still having this problem
with the latest SVN version(revision 14809) of the Lars Gullik
Bjønnes's unicode branch, using Debian Sarge with gcc version 3.3.5.
Hello Hossein,
The unicode branch has been merged in trunk. I thin
Hi.
Has anyone applied the patch on SVN? I'm still having this problem
with the latest SVN version(revision 14809) of the Lars Gullik
Bjønnes's unicode branch, using Debian Sarge with gcc version 3.3.5.
Hossein
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Georg Baum wrote:
| >> Abdelrazak Younes wrote:
| >>
| >>> No, I've reverted to 245. Maybe my problem is that lyx doesn't call the
| >>> right lyx2lyx version... I am launching lyx from the sc
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I can parse Lars pretty well now and I guess he meant "Why _not_ use..." :-)
Lars> Right. Buttered-fat-fingers it is.
I did not parse it correctly, indeed.
Lars> svn delete svn copy
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Georg Baum wrote:
| >> Abdelrazak Younes wrote:
| >>
| >>> No, I've reverted to 245. Maybe my problem is that lyx doesn't
call the
| >>> right lyx2lyx version... I a
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Georg Baum wrote:
| >> Abdelrazak Younes wrote:
| >>
| >>> No, I've reverted to 245. Maybe my problem is that lyx doesn't call the
| >>> right lyx2lyx version... I am launching lyx from the sc
Georg Baum wrote:
Abdelrazak Younes wrote:
Edwin Leuven wrote:
i think this one is only available if qt is compiled with stl
compatibility
Correct. It is inside an #ifndef QT_NO_STL block here.
The documentation doesn't state so.
Then it is incomplete, or you overread something.
I
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Georg Baum wrote:
| >> Abdelrazak Younes wrote:
| >>
| >>> No, I've reverted to 245. Maybe my problem is that lyx doesn't call the
| >>> right lyx2lyx version... I am launching lyx from the sc
Abdelrazak Younes wrote:
> Edwin Leuven wrote:
>> i think this one is only available if qt is compiled with stl
>> compatibility
Correct. It is inside an #ifndef QT_NO_STL block here.
> The documentation doesn't state so.
Then it is incomplete, or you overread something.
Georg
Edwin Leuven wrote:
Abdelrazak Younes wrote:
There is a conversion method:
std::vector QVector::toStdVector () const
i think this one is only available if qt is compiled with stl
compatibility
The documentation doesn't state so.
Abdel.
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Editing a new file or a file created by trunk lyx works: the
| characters used are latin. Also, even if all characters are in chinese
| for the help documents, newly inserted characters are latin. I think
| the problems l
Abdelrazak Younes wrote:
There is a conversion method:
std::vector QVector::toStdVector () const
i think this one is only available if qt is compiled with stl
compatibility
the attached works for me
Index: src/frontends/qt4/QLImage.C
=
Georg Baum wrote:
Abdelrazak Younes wrote:
I have converted by hand Intro.lyx:
D:\program\lyx-msvc\Resources\lyx2lyx>python lyx2lyx -t 249 -o
.\Intro.lyx ..\doc\Intro.lyx
The resulting file seems to have the correct version number:
#LyX 1.5.0svn created this file. For more info see http://www
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Editing a new file or a file created by trunk lyx works: the
| characters used are latin. Also, even if all characters are in chinese
| for the help documents, newly inserted characters are latin. I think
| the problems lies in lyx2lyx (see my other
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Edwin Leuven wrote:
| > Edwin Leuven wrote:
| >> Abdelrazak Younes wrote:
| >>> +// But Qt doc just say use bits...
| >>> +unsigned int * const data = (unsigned int *)img.bits();
| >>
| >> kde has this instead:
|
Abdelrazak Younes wrote:
> I have converted by hand Intro.lyx:
>
> D:\program\lyx-msvc\Resources\lyx2lyx>python lyx2lyx -t 249 -o
> .\Intro.lyx ..\doc\Intro.lyx
>
> The resulting file seems to have the correct version number:
> #LyX 1.5.0svn created this file. For more info see http://www.lyx.or
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Georg Baum wrote:
| >> Abdelrazak Younes wrote:
| >>
| >>> No, I've reverted to 245. Maybe my problem is that lyx doesn't call the
| >>> right lyx2lyx version... I am launching lyx from the scons build tree.
| >>
| >> Run
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Edwin Leuven wrote:
| > Edwin Leuven wrote:
| >> Abdelrazak Younes wrote:
| >>> +// But Qt doc just say use bits...
| >>> +unsigned int * const data = (unsigned int *)img.bits();
| >>
| >> kde has this instead:
| >>
| >> unsigned int *data =
Georg Baum wrote:
Abdelrazak Younes wrote:
"-dbg package" doesn't display anything for me... Here is the beginning
of the "-dbg any" output:
Sorry, that was from memory, what I meant was -dbg init.
OK
So it seems the installed version is used here. I have verified that it
is the last ver
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
| >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| > Lars> Why now use the boost from trunk?
| > The idea is to use boost 1.33(.1) to fix the crashes we see in 1.4.x
| > with
| > boost::bind and gcc 4.1.
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
No, I've reverted to 245. Maybe my problem is that lyx doesn't call the
right lyx2lyx version... I am launching lyx from the scons build tree.
Running from the build tree works for me. Run it with -dbg package,
and it
will
Abdelrazak Younes wrote:
> "-dbg package" doesn't display anything for me... Here is the beginning
> of the "-dbg any" output:
Sorry, that was from memory, what I meant was -dbg init.
> So it seems the installed version is used here. I have verified that it
> is the last version.
But it should
Jean-Marc Lasgouttes wrote:
"Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Why now use the boost from trunk?
The idea is to use boost 1.33(.1) to fix the crashes we see in 1.4.x with
boost::bind and gcc 4.1.
I can parse Lars pretty well now and I guess he meant "Why _not_ us
Edwin Leuven wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
+// But Qt doc just say use bits...
+unsigned int * const data = (unsigned int *)img.bits();
kde has this instead:
unsigned int *data = img.depth() > 8 ? (unsigned int *)img.bits() :
(unsigned int *)img.colorT
Edwin Leuven wrote:
Abdelrazak Younes wrote:
+// But Qt doc just say use bits...
+unsigned int * const data = (unsigned int *)img.bits();
kde has this instead:
unsigned int *data = img.depth() > 8 ? (unsigned int *)img.bits() :
(unsigned int *)img.colorTable();
but it tur
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Why now use the boost from trunk?
The idea is to use boost 1.33(.1) to fix the crashes we see in 1.4.x with
boost::bind and gcc 4.1.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > | >>> Conclusion: this is not a valid objection. Besides Peter is
| > | > | >>> committed to get rid of those compat methods.
| > | > | >> Then let's convince Lars t
On Sunday 20 August 2006 23:04, Lars Gullik Bjønnes wrote:
>
> - All output:
> - text (perhaps finished?)
> - latex (oh... can of worms)
> - docbook
OK. I think that the time as come to remove linuxdoc code from lyx.
I will do it soon.
> - Perhaps reading of layout fil
Jean-Marc Lasgouttes wrote:
> I guess we do not have a choice (please use 1.33.1, not 1.33).
I would use the boost from trunk, and that is 1.33.1 AFAIK.
> I
> looked at the patch between our two boost versions (branch and trunk)
> and the diff is 'only' 2.4Mb, not more than the routine po/ patc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
|
| >> Actually, in an ideal world, upgrading to 1.33.1 should not be
| >> needed either. Upgrading a full library because of what is probably
| >> a few lines worth of patch is lazy. But I
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | >>> Conclusion: this is not a valid objection. Besides Peter is
| > | >>> committed to get rid of those compat methods.
| > | >> Then let's convince Lars that this is not a showstopper :-)
| > | > Trolltech considers
Abdelrazak Younes wrote:
> No, I've reverted to 245. Maybe my problem is that lyx doesn't call the
> right lyx2lyx version... I am launching lyx from the scons build tree.
Running from the build tree works for me. Run it with -dbg package, and it
will tell you where it tries to find lyx2lyx.
Ge
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> Actually, in an ideal world, upgrading to 1.33.1 should not be
>> needed either. Upgrading a full library because of what is probably
>> a few lines worth of patch is lazy. But I do not think we have a
>> choice.
Georg> IMO investigating
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | >>> Conclusion: this is not a valid objection. Besides Peter is
| > | >>> committed to get rid of those compat methods.
| > | >> Then let's convince Lars that this is not a showstopper :-)
| > | > Trolltech considers the QT3 compat stuff as regul
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
I have changed Intro.lyx from 245 to 249 but the characters are still
chinese and there's two parse errors:
1) Unknown token: \fontscheme \fontscheme
2) Unknown token: default default
What am I doing wrong
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Abdelrazak Younes wrote:
>>
>>> I have changed Intro.lyx from 245 to 249 but the characters are still
>>> chinese and there's two parse errors:
>>> 1) Unknown token: \fontscheme \fontscheme
>>> 2) Unknown token: default default
>>>
>>> What am I doi
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Abdelrazak Younes wrote:
>>
>>> No I meant why the format is no changed to 249 so that lyx2lyx would
>>> work? That's a simple change, I can do it if you want.
>>
>> It is already at 249, and lyx2lyx works. Look at the sources ;-)
>
> I did that a
Georg Baum wrote:
Abdelrazak Younes wrote:
I have changed Intro.lyx from 245 to 249 but the characters are still
chinese and there's two parse errors:
1) Unknown token: \fontscheme \fontscheme
2) Unknown token: default default
What am I doing wrong?
You cannot simply change the format number
Georg Baum wrote:
Abdelrazak Younes wrote:
No I meant why the format is no changed to 249 so that lyx2lyx would
work? That's a simple change, I can do it if you want.
It is already at 249, and lyx2lyx works. Look at the sources ;-)
I did that and SVN update and at least FAQ.lyx and Intro.ly
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Lars Gullik Bjønnes wrote:
| >
| >> - All output:
| >> - text (perhaps finished?)
| > Not at all. I sent a simple patch that almost finished it, but in
| > discussions it turned out that it was the wrong way to do it. D
Abdelrazak Younes wrote:
> I have changed Intro.lyx from 245 to 249 but the characters are still
> chinese and there's two parse errors:
> 1) Unknown token: \fontscheme \fontscheme
> 2) Unknown token: default default
>
> What am I doing wrong?
You cannot simply change the format number and expec
Abdelrazak Younes wrote:
> No I meant why the format is no changed to 249 so that lyx2lyx would
> work? That's a simple change, I can do it if you want.
It is already at 249, and lyx2lyx works. Look at the sources ;-) Apart from
that a format change is never as simple as changing the constant in
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | 2-b) how do I fix the display of inset labels to be in english on
| > | Windows? (I suppose this is not the case under linux?)
| > ??
|
| The text in the "Foot Note", Label, etc buttons all use Chinese characters.
I think that is just the "endi
Georg Baum wrote:
Lars Gullik Bjønnes wrote:
- All output:
- text (perhaps finished?)
Not at all. I sent a simple patch that almost finished it, but in
discussions it turned out that it was the wrong way to do it. Don't you
remember?
I think we have no choice but use ucs4/docstring fo
Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > - All output:
| > - text (perhaps finished?)
|
| Not at all. I sent a simple patch that almost finished it, but in
| discussions it turned out that it was the wrong way to do it. Don't you
| remember?
| I think we
Georg Baum wrote:
Abdelrazak Younes wrote:
If lyx2lyx support is done already why don't we do the change in trunk?
Because reading the old documents simply works with the help of lyx2lyx, and
nobody volunteered to do it I guess.
No I meant why the format is no changed to 249 so that lyx2lyx
Abdelrazak Younes wrote:
> If lyx2lyx support is done already why don't we do the change in trunk?
Because reading the old documents simply works with the help of lyx2lyx, and
nobody volunteered to do it I guess. IMO it is not too important to convert
the documents now, we simply should make sure
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Someone knows how to fix it? Abdel.
Abdel, if your ISP is Free, I think there is a routing problem of some
sort (at least it was the case on saturday).
That's it then! Thanks.
Abdel.
Georg Baum wrote:
Lars Gullik Bjønnes wrote:
- All output:
- text (perhaps finished?)
Not at all. I sent a simple patch that almost finished it, but in
discussions it turned out that it was the wrong way to do it. Don't you
remember?
I think we have no choice but use ucs4/docstring fo
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| By the way, I am trying to get a grasp of what needs to be done WRT
| unicode. I feel lost in this matter and I fear that it will take a
| long time before the trunk will stabilize. Maybe I'm alone in this
| case but I nee
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Wed, Aug 16, 2006 at 05:05:53PM +0200, Abdelrazak Younes wrote:
| >> Abdelrazak Younes wrote:
| Here comes the next bit: I discovered that the result of
|
| std::vector ucs4_to_u
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Tue, Aug 15, 2006 at 11:06:16PM +0200, Michael Gerz wrote:
| >> Abdel,
| >>
| I don't know the status regarding (1) - is there anything
| missing? Are there any changes to qt3 that ha
1 - 100 of 107 matches
Mail list logo
