Re: Possible charstyle bug
Hi, I just tried editing the .lyx file manually changing \begin_inset CharStyle command status inlined \begin_layout Itemize command \end_layout \end_inset to \begin_inset CharStyle command status inlined \begin_layout Standard command \end_layout \end_inset and that fixed everything. The text is now displayed properly (no more hyphen to symbolize nested itemizing) and the LaTeX code is also correct. That means things go wrong when character styles are *added* to an itemize structure. Regards, Markus
Possible charstyle bug
Hi,
I think I may have found a bug in the way character styles are handled.
See attached sample document and sample styles.
If a character style is used in an "itemize" environment, LyX
genereates LaTeX code like this:
\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{\begin{itemize}
\item command
\end{itemize}
} and then some more text
...
That's not the intention. There is no reason to repeat "itemize" inside
the "command" character style. It should have been
\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{command} and then some more text
...
But not only does LyX generate a nested "itemize" structure, it also
displays it like that (no line breaks around "command", but a "-" in
front of it to symbolize the 2nd level of itemize).
Regards,
Markus
#% Do not delete the line below; configure depends on this
# \DeclareLaTeXClass[article]{MM Article}
# Markus' Article textclass definition file.
# Author : Markus Mayer
Input article.layout
Input mm_charstyles.inc
# Textclass definition file for article.
# Character Styles definition
Format 2
CharStyle filename
LatexType Command
LatexName textsf
Font
Family Sans
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle variable
LatexType Command
LatexName textsf
Font
Family Sans
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle command
LatexType Command
LatexName texttt
Font
Family Typewriter
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle code
LatexType Command
LatexName texttt
Font
Family Typewriter
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
#LyX 1.4.0 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass mm_article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header
\begin_body
\begin_layout Standard
Enumeration test
\end_layout
\begin_layout Itemize
item 1
\end_layout
\begin_layout Itemize
item 2
\end_layout
\begin_layout Itemize
item 3 has a
\begin_inset CharStyle command
status inlined
\begin_layout Itemize
command
\end_layout
\end_inset
and then some more text
\end_layout
\begin_layout Itemize
item 4 has a
\begin_inset CharStyle filename
status inlined
\begin_layout Itemize
filename
\end_layout
\end_inset
and then some more text
\end_layout
\begin_layout Itemize
item 5
\end_layout
\begin_layout Standard
That's it.
\end_layout
\end_body
\end_document
charstyle-bug.tex
Description: TeX document
1.4.0 Source Code bug under Solaris x86
Hi,
I just built and packaged LyX 1.4.0 for the Blastwave project. I found
that the following error occurs (x86 only, not SPARC):
/opt/csw/gcc3/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../../src -Winvalid-pch
--include=./pch.h -I./.. -I../../boost -I/opt/csw/include
-I/usr/openwin/include -fno-exceptions -O2 -MT filetools.lo -MD -MP -MF
.deps/filetools.Tpo -c filetools.C -o filetools.o
In file included from ../../src/debug.h:16,
from filetools.C:37:
../../src/support/debugstream.h:30: error: expected identifier before numeric
constant
../../src/support/debugstream.h:30: error: expected `}' before numeric constant
../../src/support/debugstream.h:30: error: expected unqualified-id before
numeric constant
../../src/support/debugstream.h:38: error: `type' was not declared in this scope
../../src/support/debugstream.h:38: error: `type' was not declared in this scope
../../src/support/debugstream.h:38: error: initializer expression list treated
as compound expression
../../src/support/debugstream.h:38: error: expected `,' or `;' before '{' token
../../src/support/debugstream.h:41: error: expected declaration before '}' token
In file included from ../../src/debug.h:16,
from filetools.C:37:
../../src/support/debugstream.h:12:1: unterminated #ifndef
In file included from filetools.C:37:
../../src/debug.h:13:1: unterminated #ifndef
gmake[2]: *** [filetools.lo] Error 1
This is problem is very similar to the issue I reported on Oct. 26,
2005. It's even the same file that's at fault this time as well.
Solaris 8 x86 defines the constant "ERR".
/usr/include/ia32/sys/reg.h contains:
#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
[...]
#define ERR 13
[...]
#endif /* !defined(_XPG4_2) || defined(__EXTENSIONS__) */
The quick solution would be to apply the attached patch. Alternatively
(and probably better) would be to
*) ensure _XPG4_2 is defined
*) ensure __EXTENSIONS__ is not defined
unless this causes problems in other parts of the code. I have not
looked at that myself yet.
I don't like the "#undef ERR" patch too much as it is a little hacky
and could potentially have side-effects on other architectures, but for
now it works. I could successfully build LyX.
Regards,
Markus
diff -ru orig/lyx-1.4.0/src/support/debugstream.h
lyx-1.4.0/src/support/debugstream.h
--- orig/lyx-1.4.0/src/support/debugstream.h2004-05-20 02:35:30.0
-0700
+++ lyx-1.4.0/src/support/debugstream.h 2006-03-15 21:43:47.757653000 -0800
@@ -21,6 +21,10 @@
# undef DEBUG
#endif
+#ifdef ERR
+#undef ERR
+#endif
+
struct debug_trait {
enum type {
NONE = 0,
Re: Solaris x86 issues
On Thursday, 03 Nov 2005 12:03 +0100, Jean-Marc Lasgouttes wrote: > I committed the patches with the #ifdef, since it does not hurt. Thanks a lot! Going to save me some trouble when I'm going to package up a new version of LyX. -Markus -- http://www.blastwave.org
Re: Solaris x86 issues
On Wednesday, 26 Oct 2005 00:22 +0100, John Levon wrote: > Rather, we should do the > > #ifdef SP > #undef SP > #endif > > approach mentioned in the bug. That way, when nobody uses Solaris 9 or > earlier any more (it won't happen on S10), it's easy to remove the hack. That is true. It won't affect any other platform/architecture than Solaris x86 then. I this case I would do something like /** * Solaris x86 hack * (Solaris x86 defines SP and PC in /usr/include/ia32/sys/reg.h) */ #if (defined(__i386) && defined(sun) && defined(__SVR4)) #undef SP #undef PC #endif (Note: It is __SVR4 in my example, not SVR4 as in the original patch, which does not work.) We use Solaris 8 on our Blastwave build-machines, by the way. This is to ensure that the packages we produce run on Solaris 8 and up. It's most likely going to stay like that till Sun announces the End-of-Life for Solaris 8. -Markus
Solaris x86 issues
Hi,
I took over maintaining LyX for the Blastwave project
(http://www.blastwave.org/) which provides packaged open source
software for the Solaris platform (inspired by Debian).
While there were no problems compiling LyX for the SPARC architecture,
on x86 I ran into a compiler error:
[...]
/opt/csw/gcc3/bin/g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost
-I/opt/csw/include -isystem /usr/openwin/include -O2 -c -o MenuBackend.o
MenuBackend.C
In file included from lyxgluelength.h:14,
from vspace.h:13,
from bufferparams.h:16,
from buffer.h:21,
from MenuBackend.C:23:
lyxlength.h:23: error: expected identifier before numeric constant
lyxlength.h:23: error: expected }' before numeric constant
lyxlength.h:23: error: expected unqualified-id before numeric constant
lyxlength.h:45: error: expected unqualified-id before ')' token
[...]
It took a while to figure out what the reason was and I just discovered
that it is even a known issue and that a bug-fix has been proposed two
and a half years ago (http://bugzilla.lyx.org/show_bug.cgi?id=992).
I took this patch and tried it out. While it is a good idea to save the
old values of SP and PC and restore them later, I don't think the C
preprocessor works like this. At least my tests indicated that
#define SAVED_SP SP
will just set SAVED_SP to the litteral value of SP not the value of the
macro SP (which is 7).
So I tried an alternative approach (renaming SP and PC). This patch is
surprisingly small (requires only two changes in lyxlength.h and
lyxlength.C).
Would it be possible to consider this patch (or a modified version of
the proposed patch from 2003) for application to the mainline?
Best regards,
-Markus
diff -ru lyx-1.3.6.orig/src/lyxlength.C lyx-1.3.6/src/lyxlength.C
--- lyx-1.3.6.orig/src/lyxlength.C 2005-01-19 06:49:49.0 -0800
+++ lyx-1.3.6/src/lyxlength.C 2005-10-25 15:33:30.932284000 -0700
@@ -141,7 +141,7 @@
double result = 0.0;
switch (unit_) {
- case LyXLength::SP:
+ case LyXLength::SC:
// Scaled point: sp = 1/65536 pt
result = zoom * dpi * val_
/ (72.27 * 65536); // 4736286.7
@@ -166,7 +166,7 @@
result = zoom * dpi * val_
/ 25.4; // 25.4
break;
- case LyXLength::PC:
+ case LyXLength::PI:
// Pica: 1 pc = 12 pt
result = zoom * dpi * val_
/ (72.27 / 12); // 6.0225
diff -ru lyx-1.3.6.orig/src/lyxlength.h lyx-1.3.6/src/lyxlength.h
--- lyx-1.3.6.orig/src/lyxlength.h 2004-12-21 07:31:23.0 -0800
+++ lyx-1.3.6/src/lyxlength.h 2005-10-25 14:29:42.0 -0700
@@ -20,12 +20,12 @@
public:
/// length units
enum UNIT {
- SP, ///< Scaled point (65536sp = 1pt) TeX's smallest unit.
+ SC, ///< Scaled point (65536sp = 1pt) TeX's smallest unit.
PT, ///< Point = 1/72.27in = 0.351mm
BP, ///< Big point (72bp = 1in), also PostScript point
DD, ///< Didot point = 1/72 of a French inch, = 0.376mm
MM, ///< Millimeter = 2.845pt
- PC, ///< Pica = 12pt = 4.218mm
+ PI, ///< Pica = 12pt = 4.218mm
CC, ///< Cicero = 12dd = 4.531mm
CM, ///< Centimeter = 10mm = 2.371pc
IN, ///< Inch = 25.4mm = 72.27pt = 6.022pc
