Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote:
This is definitely the right solution. Getting rid of special casing
is always better.
Attached is the patch. Works like a charm.
The second patch is an update to LaTeXConfig.lyx.in and chkconfig.ltx.
OK to apply?
Jürgen
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.630
diff -p -u -r1.630 buffer.C
--- src/buffer.C 29 Nov 2005 15:08:34 - 1.630
+++ src/buffer.C 26 Jan 2006 09:09:06 -
@@ -1157,10 +1157,8 @@ void Buffer::validate(LaTeXFeatures fe
LyXTextClass const tclass = params().getLyXTextClass();
if (features.isAvailable(dvipost) params().tracking_changes
- params().output_changes) {
+ params().output_changes)
features.require(dvipost);
- features.require(color);
- }
// AMS Style is at document level
if (params().use_amsmath == BufferParams::AMS_ON
Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.119
diff -p -u -r1.119 LaTeXFeatures.C
--- src/LaTeXFeatures.C 11 Jun 2005 11:02:22 - 1.119
+++ src/LaTeXFeatures.C 26 Jan 2006 09:09:07 -
@@ -281,13 +281,11 @@ string const LaTeXFeatures::getPackages(
// color.sty
if (isRequired(color)) {
- if (params_.graphicsDriver == default)
- packages \\usepackage[usenames]{color}\n;
- else
- packages \\usepackage[
+ if (params_.graphicsDriver != default)
+ packages \\PassOptionsToPackage{
params_.graphicsDriver
- ,usenames
- ]{color}\n;
+ }{color}\n;
+ packages \\usepackage{color}\n;
}
// makeidx.sty
Index: lib/chkconfig.ltx
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/chkconfig.ltx,v
retrieving revision 1.15
diff -u -r1.15 chkconfig.ltx
--- lib/chkconfig.ltx 16 Dec 2004 14:46:49 - 1.15
+++ lib/chkconfig.ltx 26 Jan 2006 09:14:09 -
@@ -215,8 +215,6 @@
%%% Packages
-\TestPackage{a4}
-\TestPackage{a4wide}
\TestPackage{array}
\TestPackage{babel}
\TestPackage{color} % this one should be there if graphics.sty is there.
@@ -233,6 +231,8 @@
\TestPackage{varioref}
\TestPackage{prettyref}
\TestPackage{natbib}
+\TestPackage{bibtopic}
+\TestPackage{jurabib}
\TestPackage{dvipost}
% The test for the graphics package is slightly more involved...
Index: lib/doc/LaTeXConfig.lyx.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LaTeXConfig.lyx.in,v
retrieving revision 1.43
diff -u -r1.43 LaTeXConfig.lyx.in
--- lib/doc/LaTeXConfig.lyx.in 25 Oct 2005 08:58:07 - 1.43
+++ lib/doc/LaTeXConfig.lyx.in 26 Jan 2006 09:14:11 -
@@ -2073,54 +2073,6 @@
\end_layout
\begin_layout Subsection
-a4
-\end_layout
-
-\begin_layout Description
-Found: @chk_a4@
-\end_layout
-
-\begin_layout Description
-CTAN:
-\family typewriter
-macros/latex/contrib/ntgclass/
-\end_layout
-
-\begin_layout Description
-Notes: The package
-\family sans
-a4
-\family default
- changes the margins of your document to suit the European A4 page dimensions
- with smaller margins that the default A4 format.
-\end_layout
-
-\begin_layout Subsection
-a4wide
-\end_layout
-
-\begin_layout Description
-Found: @chk_a4wide@
-\end_layout
-
-\begin_layout Description
-CTAN:
-\family typewriter
-macros/latex/contrib/misc/
-\end_layout
-
-\begin_layout Description
-Notes: The package
-\family sans
-a4wide
-\family default
- is another package that allows setting of the margins of your document
- to A4 paper.
- With this package, the margins are very wide, but do not follow typographical
- conventions.
-\end_layout
-
-\begin_layout Subsection
geometry
\end_layout
@@ -2215,6 +2167,36 @@
bibtopic
\family default
is used to split BibTeX created bibliographies into sections.
+\end_layout
+
+\begin_layout Subsection
+dvipost
+\end_layout
+
+\begin_layout Description
+Found: @chk_dvipost@
+\end_layout
+
+\begin_layout Description
+URL:
+\family sans
+http://freshmeat.net/projects/dvipost/
+\end_layout
+
+\begin_layout Description
+Notes:
+\family sans
+dvipost
+\family default
+ is a post-processor for DVI files created by LaTeX and TeX.
+ It is needed by LyX to generate DVI or Postscript output of change tracking
+ marks.
+ To work properly,
+\family sans
+dvipost
+\family default
+needs teTeX version 2 or newer.
+
\end_layout
\begin_layout Subsection
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller [EMAIL PROTECTED] writes:
| Jean-Marc Lasgouttes wrote:
| This is definitely the right solution. Getting rid of special casing
| is always better.
|
| Attached is the patch. Works like a charm.
| The second patch is an update to LaTeXConfig.lyx.in and chkconfig.ltx.
|
| OK to apply?
| Jürgen
|
| Index: src/buffer.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
| retrieving revision 1.630
| diff -p -u -r1.630 buffer.C
| --- src/buffer.C 29 Nov 2005 15:08:34 - 1.630
| +++ src/buffer.C 26 Jan 2006 09:09:06 -
| @@ -1157,10 +1157,8 @@ void Buffer::validate(LaTeXFeatures fe
| LyXTextClass const tclass = params().getLyXTextClass();
|
| if (features.isAvailable(dvipost) params().tracking_changes
| - params().output_changes) {
| + params().output_changes)
| features.require(dvipost);
| - features.require(color);
| - }
This is ok since it is for change tracking and we have not supported
that before.
| // AMS Style is at document level
| if (params().use_amsmath == BufferParams::AMS_ON
| Index: src/LaTeXFeatures.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
| retrieving revision 1.119
| diff -p -u -r1.119 LaTeXFeatures.C
| --- src/LaTeXFeatures.C 11 Jun 2005 11:02:22 - 1.119
| +++ src/LaTeXFeatures.C 26 Jan 2006 09:09:07 -
| @@ -281,13 +281,11 @@ string const LaTeXFeatures::getPackages(
|
| // color.sty
| if (isRequired(color)) {
| - if (params_.graphicsDriver == default)
| - packages \\usepackage[usenames]{color}\n;
| - else
| - packages \\usepackage[
| + if (params_.graphicsDriver != default)
| + packages \\PassOptionsToPackage{
| params_.graphicsDriver
| - ,usenames
| - ]{color}\n;
| + }{color}\n;
| + packages \\usepackage{color}\n;
| }
This one I am a bit more wary about. I am absolutely not certain that
this won't have unforseen consequences.
IMHO this should be held for later releases.
| // makeidx.sty
|
| Index: lib/chkconfig.ltx
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/chkconfig.ltx,v
| retrieving revision 1.15
| diff -u -r1.15 chkconfig.ltx
| --- lib/chkconfig.ltx 16 Dec 2004 14:46:49 - 1.15
| +++ lib/chkconfig.ltx 26 Jan 2006 09:14:09 -
| @@ -215,8 +215,6 @@
|
|
| %%% Packages
| -\TestPackage{a4}
| -\TestPackage{a4wide}
| \TestPackage{array}
| \TestPackage{babel}
| \TestPackage{color} % this one should be there if graphics.sty is there.
| @@ -233,6 +231,8 @@
| \TestPackage{varioref}
| \TestPackage{prettyref}
| \TestPackage{natbib}
| +\TestPackage{bibtopic}
| +\TestPackage{jurabib}
Are these already mentioned in LaTeXConfig? Or is it not needed?
| \TestPackage{dvipost}
|
| % The test for the graphics package is slightly more involved...
| Index: lib/doc/LaTeXConfig.lyx.in
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LaTeXConfig.lyx.in,v
| retrieving revision 1.43
| diff -u -r1.43 LaTeXConfig.lyx.in
| --- lib/doc/LaTeXConfig.lyx.in25 Oct 2005 08:58:07 - 1.43
| +++ lib/doc/LaTeXConfig.lyx.in26 Jan 2006 09:14:11 -
| @@ -2073,54 +2073,6 @@
The added section on dvipost is good.
Get OK from J-M before removing the others from the doc.
(I would have preferred two different patches for this)
--
Lgb
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Lars Gullik Bjønnes wrote:
| // color.sty
| if (isRequired(color)) {
| - if (params_.graphicsDriver == default)
| - packages \\usepackage[usenames]{color}\n;
| - else
| - packages \\usepackage[
| + if (params_.graphicsDriver != default)
| + packages \\PassOptionsToPackage{
| params_.graphicsDriver
| - ,usenames
| - ]{color}\n;
| + }{color}\n;
| + packages \\usepackage{color}\n;
| }
This one I am a bit more wary about. I am absolutely not certain that
this won't have unforseen consequences.
IMHO this should be held for later releases.
OK, but to resolve the bug we need at least the attached. Note that usenames
has been introduced *only* for dvipost (we didn't use it in 1.3).
(also note that this version is likely to still cause conflicts, e.g. for
beamer and non-standard ps driver, but that's no regression).
| +\TestPackage{bibtopic}
| +\TestPackage{jurabib}
Are these already mentioned in LaTeXConfig? Or is it not needed?
They are already mentioned. Apparently, I forgot to add the above entries when
I did the entries in LaTeXConfig.
| \TestPackage{dvipost}
|
| % The test for the graphics package is slightly more involved...
| Index: lib/doc/LaTeXConfig.lyx.in
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LaTeXConfig.lyx.in,v
| retrieving revision 1.43
| diff -u -r1.43 LaTeXConfig.lyx.in
| --- lib/doc/LaTeXConfig.lyx.in 25 Oct 2005 08:58:07 - 1.43
| +++ lib/doc/LaTeXConfig.lyx.in 26 Jan 2006 09:14:11 -
| @@ -2073,54 +2073,6 @@
The added section on dvipost is good.
Get OK from J-M before removing the others from the doc.
OK.
(I would have preferred two different patches for this)
Next time.
Jürgen
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.630
diff -p -u -r1.630 buffer.C
--- src/buffer.C 29 Nov 2005 15:08:34 - 1.630
+++ src/buffer.C 26 Jan 2006 09:46:55 -
@@ -1157,10 +1157,8 @@ void Buffer::validate(LaTeXFeatures fe
LyXTextClass const tclass = params().getLyXTextClass();
if (features.isAvailable(dvipost) params().tracking_changes
- params().output_changes) {
+ params().output_changes)
features.require(dvipost);
- features.require(color);
- }
// AMS Style is at document level
if (params().use_amsmath == BufferParams::AMS_ON
Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.119
diff -p -u -r1.119 LaTeXFeatures.C
--- src/LaTeXFeatures.C 11 Jun 2005 11:02:22 - 1.119
+++ src/LaTeXFeatures.C 26 Jan 2006 09:46:56 -
@@ -282,11 +282,10 @@ string const LaTeXFeatures::getPackages(
// color.sty
if (isRequired(color)) {
if (params_.graphicsDriver == default)
- packages \\usepackage[usenames]{color}\n;
+ packages \\usepackage{color}\n;
else
packages \\usepackage[
params_.graphicsDriver
- ,usenames
]{color}\n;
}
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| | // color.sty
| | if (isRequired(color)) {
| | - if (params_.graphicsDriver == default)
| | - packages \\usepackage[usenames]{color}\n;
| | - else
| | - packages \\usepackage[
| | + if (params_.graphicsDriver != default)
| | + packages \\PassOptionsToPackage{
| | params_.graphicsDriver
| | - ,usenames
| | - ]{color}\n;
| | + }{color}\n;
| | + packages \\usepackage{color}\n;
| | }
|
| This one I am a bit more wary about. I am absolutely not certain that
| this won't have unforseen consequences.
| IMHO this should be held for later releases.
|
| OK, but to resolve the bug we need at least the attached.
Ok.
--
Lgb
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars The added section on dvipost is good. Get OK from J-M before Lars removing the others from the doc. (I would have preferred two Lars different patches for this) All these changes are OK. JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Lars Gullik Bjønnes wrote: | OK, but to resolve the bug we need at least the attached. Ok. Thanks. I'll apply this and wait with the LaTeXConfig stuff for Jean-Marcs approval. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote:
> This is definitely the right solution. Getting rid of special casing
> is always better.
Attached is the patch. Works like a charm.
The second patch is an update to LaTeXConfig.lyx.in and chkconfig.ltx.
OK to apply?
Jürgen
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.630
diff -p -u -r1.630 buffer.C
--- src/buffer.C 29 Nov 2005 15:08:34 - 1.630
+++ src/buffer.C 26 Jan 2006 09:09:06 -
@@ -1157,10 +1157,8 @@ void Buffer::validate(LaTeXFeatures & fe
LyXTextClass const & tclass = params().getLyXTextClass();
if (features.isAvailable("dvipost") && params().tracking_changes
- && params().output_changes) {
+ && params().output_changes)
features.require("dvipost");
- features.require("color");
- }
// AMS Style is at document level
if (params().use_amsmath == BufferParams::AMS_ON
Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.119
diff -p -u -r1.119 LaTeXFeatures.C
--- src/LaTeXFeatures.C 11 Jun 2005 11:02:22 - 1.119
+++ src/LaTeXFeatures.C 26 Jan 2006 09:09:07 -
@@ -281,13 +281,11 @@ string const LaTeXFeatures::getPackages(
// color.sty
if (isRequired("color")) {
- if (params_.graphicsDriver == "default")
- packages << "\\usepackage[usenames]{color}\n";
- else
- packages << "\\usepackage["
+ if (params_.graphicsDriver != "default")
+ packages << "\\PassOptionsToPackage{"
<< params_.graphicsDriver
- << ",usenames"
- << "]{color}\n";
+ << "}{color}\n";
+ packages << "\\usepackage{color}\n";
}
// makeidx.sty
Index: lib/chkconfig.ltx
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/chkconfig.ltx,v
retrieving revision 1.15
diff -u -r1.15 chkconfig.ltx
--- lib/chkconfig.ltx 16 Dec 2004 14:46:49 - 1.15
+++ lib/chkconfig.ltx 26 Jan 2006 09:14:09 -
@@ -215,8 +215,6 @@
%%% Packages
-\TestPackage{a4}
-\TestPackage{a4wide}
\TestPackage{array}
\TestPackage{babel}
\TestPackage{color} % this one should be there if graphics.sty is there.
@@ -233,6 +231,8 @@
\TestPackage{varioref}
\TestPackage{prettyref}
\TestPackage{natbib}
+\TestPackage{bibtopic}
+\TestPackage{jurabib}
\TestPackage{dvipost}
% The test for the graphics package is slightly more involved...
Index: lib/doc/LaTeXConfig.lyx.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LaTeXConfig.lyx.in,v
retrieving revision 1.43
diff -u -r1.43 LaTeXConfig.lyx.in
--- lib/doc/LaTeXConfig.lyx.in 25 Oct 2005 08:58:07 - 1.43
+++ lib/doc/LaTeXConfig.lyx.in 26 Jan 2006 09:14:11 -
@@ -2073,54 +2073,6 @@
\end_layout
\begin_layout Subsection
-a4
-\end_layout
-
-\begin_layout Description
-Found: @chk_a4@
-\end_layout
-
-\begin_layout Description
-CTAN:
-\family typewriter
-macros/latex/contrib/ntgclass/
-\end_layout
-
-\begin_layout Description
-Notes: The package
-\family sans
-a4
-\family default
- changes the margins of your document to suit the European A4 page dimensions
- with smaller margins that the default A4 format.
-\end_layout
-
-\begin_layout Subsection
-a4wide
-\end_layout
-
-\begin_layout Description
-Found: @chk_a4wide@
-\end_layout
-
-\begin_layout Description
-CTAN:
-\family typewriter
-macros/latex/contrib/misc/
-\end_layout
-
-\begin_layout Description
-Notes: The package
-\family sans
-a4wide
-\family default
- is another package that allows setting of the margins of your document
- to A4 paper.
- With this package, the margins are very wide, but do not follow typographical
- conventions.
-\end_layout
-
-\begin_layout Subsection
geometry
\end_layout
@@ -2215,6 +2167,36 @@
bibtopic
\family default
is used to split BibTeX created bibliographies into sections.
+\end_layout
+
+\begin_layout Subsection
+dvipost
+\end_layout
+
+\begin_layout Description
+Found: @chk_dvipost@
+\end_layout
+
+\begin_layout Description
+URL:
+\family sans
+http://freshmeat.net/projects/dvipost/
+\end_layout
+
+\begin_layout Description
+Notes:
+\family sans
+dvipost
+\family default
+ is a post-processor for DVI files created by LaTeX and TeX.
+ It is needed by LyX to generate DVI or Postscript output of change tracking
+ marks.
+ To work properly,
+\family sans
+dvipost
+\family default
+needs teTeX version 2 or newer.
+
\end_layout
\begin_layout Subsection
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
| > This is definitely the right solution. Getting rid of special casing
| > is always better.
|
| Attached is the patch. Works like a charm.
| The second patch is an update to LaTeXConfig.lyx.in and chkconfig.ltx.
|
| OK to apply?
| Jürgen
|
| Index: src/buffer.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
| retrieving revision 1.630
| diff -p -u -r1.630 buffer.C
| --- src/buffer.C 29 Nov 2005 15:08:34 - 1.630
| +++ src/buffer.C 26 Jan 2006 09:09:06 -
| @@ -1157,10 +1157,8 @@ void Buffer::validate(LaTeXFeatures & fe
| LyXTextClass const & tclass = params().getLyXTextClass();
|
| if (features.isAvailable("dvipost") && params().tracking_changes
| - && params().output_changes) {
| + && params().output_changes)
| features.require("dvipost");
| - features.require("color");
| - }
This is ok since it is for change tracking and we have not supported
that before.
| // AMS Style is at document level
| if (params().use_amsmath == BufferParams::AMS_ON
| Index: src/LaTeXFeatures.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
| retrieving revision 1.119
| diff -p -u -r1.119 LaTeXFeatures.C
| --- src/LaTeXFeatures.C 11 Jun 2005 11:02:22 - 1.119
| +++ src/LaTeXFeatures.C 26 Jan 2006 09:09:07 -
| @@ -281,13 +281,11 @@ string const LaTeXFeatures::getPackages(
|
| // color.sty
| if (isRequired("color")) {
| - if (params_.graphicsDriver == "default")
| - packages << "\\usepackage[usenames]{color}\n";
| - else
| - packages << "\\usepackage["
| + if (params_.graphicsDriver != "default")
| + packages << "\\PassOptionsToPackage{"
|<< params_.graphicsDriver
| - << ",usenames"
| - << "]{color}\n";
| + << "}{color}\n";
| + packages << "\\usepackage{color}\n";
| }
This one I am a bit more wary about. I am absolutely not certain that
this won't have unforseen consequences.
IMHO this should be held for later releases.
| // makeidx.sty
|
| Index: lib/chkconfig.ltx
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/chkconfig.ltx,v
| retrieving revision 1.15
| diff -u -r1.15 chkconfig.ltx
| --- lib/chkconfig.ltx 16 Dec 2004 14:46:49 - 1.15
| +++ lib/chkconfig.ltx 26 Jan 2006 09:14:09 -
| @@ -215,8 +215,6 @@
|
|
| %%% Packages
| -\TestPackage{a4}
| -\TestPackage{a4wide}
| \TestPackage{array}
| \TestPackage{babel}
| \TestPackage{color} % this one should be there if graphics.sty is there.
| @@ -233,6 +231,8 @@
| \TestPackage{varioref}
| \TestPackage{prettyref}
| \TestPackage{natbib}
| +\TestPackage{bibtopic}
| +\TestPackage{jurabib}
Are these already mentioned in LaTeXConfig? Or is it not needed?
| \TestPackage{dvipost}
|
| % The test for the graphics package is slightly more involved...
| Index: lib/doc/LaTeXConfig.lyx.in
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LaTeXConfig.lyx.in,v
| retrieving revision 1.43
| diff -u -r1.43 LaTeXConfig.lyx.in
| --- lib/doc/LaTeXConfig.lyx.in25 Oct 2005 08:58:07 - 1.43
| +++ lib/doc/LaTeXConfig.lyx.in26 Jan 2006 09:14:11 -
| @@ -2073,54 +2073,6 @@
The added section on dvipost is good.
Get OK from J-M before removing the others from the doc.
(I would have preferred two different patches for this)
--
Lgb
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Lars Gullik Bjønnes wrote:
> | // color.sty
> | if (isRequired("color")) {
> | - if (params_.graphicsDriver == "default")
> | - packages << "\\usepackage[usenames]{color}\n";
> | - else
> | - packages << "\\usepackage["
> | + if (params_.graphicsDriver != "default")
> | + packages << "\\PassOptionsToPackage{"
> | << params_.graphicsDriver
> | -<< ",usenames"
> | -<< "]{color}\n";
> | +<< "}{color}\n";
> | + packages << "\\usepackage{color}\n";
> | }
>
> This one I am a bit more wary about. I am absolutely not certain that
> this won't have unforseen consequences.
> IMHO this should be held for later releases.
OK, but to resolve the bug we need at least the attached. Note that "usenames"
has been introduced *only* for dvipost (we didn't use it in 1.3).
(also note that this version is likely to still cause conflicts, e.g. for
beamer and non-standard ps driver, but that's no regression).
> | +\TestPackage{bibtopic}
> | +\TestPackage{jurabib}
>
> Are these already mentioned in LaTeXConfig? Or is it not needed?
They are already mentioned. Apparently, I forgot to add the above entries when
I did the entries in LaTeXConfig.
> | \TestPackage{dvipost}
> |
> | % The test for the graphics package is slightly more involved...
> | Index: lib/doc/LaTeXConfig.lyx.in
> | ===
> | RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LaTeXConfig.lyx.in,v
> | retrieving revision 1.43
> | diff -u -r1.43 LaTeXConfig.lyx.in
> | --- lib/doc/LaTeXConfig.lyx.in 25 Oct 2005 08:58:07 - 1.43
> | +++ lib/doc/LaTeXConfig.lyx.in 26 Jan 2006 09:14:11 -
> | @@ -2073,54 +2073,6 @@
>
> The added section on dvipost is good.
> Get OK from J-M before removing the others from the doc.
OK.
> (I would have preferred two different patches for this)
Next time.
Jürgen
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.630
diff -p -u -r1.630 buffer.C
--- src/buffer.C 29 Nov 2005 15:08:34 - 1.630
+++ src/buffer.C 26 Jan 2006 09:46:55 -
@@ -1157,10 +1157,8 @@ void Buffer::validate(LaTeXFeatures & fe
LyXTextClass const & tclass = params().getLyXTextClass();
if (features.isAvailable("dvipost") && params().tracking_changes
- && params().output_changes) {
+ && params().output_changes)
features.require("dvipost");
- features.require("color");
- }
// AMS Style is at document level
if (params().use_amsmath == BufferParams::AMS_ON
Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.119
diff -p -u -r1.119 LaTeXFeatures.C
--- src/LaTeXFeatures.C 11 Jun 2005 11:02:22 - 1.119
+++ src/LaTeXFeatures.C 26 Jan 2006 09:46:56 -
@@ -282,11 +282,10 @@ string const LaTeXFeatures::getPackages(
// color.sty
if (isRequired("color")) {
if (params_.graphicsDriver == "default")
- packages << "\\usepackage[usenames]{color}\n";
+ packages << "\\usepackage{color}\n";
else
packages << "\\usepackage["
<< params_.graphicsDriver
- << ",usenames"
<< "]{color}\n";
}
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > | // color.sty
| > | if (isRequired("color")) {
| > | - if (params_.graphicsDriver == "default")
| > | - packages << "\\usepackage[usenames]{color}\n";
| > | - else
| > | - packages << "\\usepackage["
| > | + if (params_.graphicsDriver != "default")
| > | + packages << "\\PassOptionsToPackage{"
| > |<< params_.graphicsDriver
| > | - << ",usenames"
| > | - << "]{color}\n";
| > | + << "}{color}\n";
| > | + packages << "\\usepackage{color}\n";
| > | }
| >
| > This one I am a bit more wary about. I am absolutely not certain that
| > this won't have unforseen consequences.
| > IMHO this should be held for later releases.
|
| OK, but to resolve the bug we need at least the attached.
Ok.
--
Lgb
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> The added section on dvipost is good. Get OK from J-M before Lars> removing the others from the doc. (I would have preferred two Lars> different patches for this) All these changes are OK. JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Lars Gullik Bjønnes wrote: > | OK, but to resolve the bug we need at least the attached. > > Ok. Thanks. I'll apply this and wait with the LaTeXConfig stuff for Jean-Marcs approval. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Am Dienstag, 24. Januar 2006 14:28 schrieb Juergen Spitzmueller: It is not depending on the dvipost version, but on the teTeX version (i.e. dvips, according to E. Frühstück). I think we can just demnd teTeX 2.x to be installed (otherwise people just don't see the ct marks in the output). Agreed, especially since tetex 2 is out for years. Georg
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Am Dienstag, 24. Januar 2006 14:28 schrieb Juergen Spitzmueller: > It is not depending on the dvipost version, but on the teTeX version (i.e. > dvips, according to E. Frühstück). I think we can just demnd teTeX 2.x to > be installed (otherwise people just don't see the ct marks in the output). Agreed, especially since tetex 2 is out for years. Georg
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote: Beamer apparently loads color. Either color and xcolor are loaded by beamer, or xcolor pretends that it is color. The situation has changed. I had some conversation with Erich Frühstück, the author of dvipost. He responded that dvipost doesn't require color.sty at all (anymore), at least since teTeX 2. So the easiest solution would be to get rid of the color requirement for dvipost (and, if needed, require teTeX = 2 for change tracking). Then all conflicts would just go away. What do cou think? Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen The situation has changed. I had some conversation with Erich Juergen Frühstück, the author of dvipost. He responded that dvipost Juergen doesn't require color.sty at all (anymore), at least since Juergen teTeX 2. Juergen So the easiest solution would be to get rid of the color Juergen requirement for dvipost (and, if needed, require teTeX = 2 Juergen for change tracking). Then all conflicts would just go away. This is definitely the right solution. Getting rid of special casing is always better. I like that. JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote:
Juergen == Juergen Spitzmueller
[EMAIL PROTECTED] writes:
Juergen So the easiest solution would be to get rid of the color
Juergen requirement for dvipost (and, if needed, require teTeX = 2
Juergen for change tracking). Then all conflicts would just go away.
This can be done by loading dvipost with \usepackage{dvipost}[date], where
date is the date of the first dvipost release that works.
This is definitely the right solution. Getting rid of special casing
is always better.
I like that.
Me too.
Georg
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Georg Baum wrote:
This can be done by loading dvipost with \usepackage{dvipost}[date], where
date is the date of the first dvipost release that works.
It is not depending on the dvipost version, but on the teTeX version (i.e.
dvips, according to E. Frühstück). I think we can just demnd teTeX 2.x to
be installed (otherwise people just don't see the ct marks in the output).
This is definitely the right solution. Getting rid of special casing
is always better.
I like that.
Me too.
Me as well. I'll post a patch later this week.
Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote: > Beamer apparently loads color. Either color and xcolor are loaded by > beamer, or xcolor pretends that it is color. The situation has changed. I had some conversation with Erich Frühstück, the author of dvipost. He responded that dvipost doesn't require color.sty at all (anymore), at least since teTeX 2. So the easiest solution would be to get rid of the color requirement for dvipost (and, if needed, require teTeX >= 2 for change tracking). Then all conflicts would just go away. What do cou think? Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> The situation has changed. I had some conversation with Erich Juergen> Frühstück, the author of dvipost. He responded that dvipost Juergen> doesn't require color.sty at all (anymore), at least since Juergen> teTeX 2. Juergen> So the easiest solution would be to get rid of the color Juergen> requirement for dvipost (and, if needed, require teTeX >= 2 Juergen> for change tracking). Then all conflicts would just go away. This is definitely the right solution. Getting rid of special casing is always better. I like that. JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote:
>> "Juergen" == Juergen Spitzmueller
>> <[EMAIL PROTECTED]> writes:
> Juergen> So the easiest solution would be to get rid of the color
> Juergen> requirement for dvipost (and, if needed, require teTeX >= 2
> Juergen> for change tracking). Then all conflicts would just go away.
This can be done by loading dvipost with \usepackage{dvipost}[date], where
date is the date of the first dvipost release that works.
> This is definitely the right solution. Getting rid of special casing
> is always better.
>
> I like that.
Me too.
Georg
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Georg Baum wrote:
> This can be done by loading dvipost with \usepackage{dvipost}[date], where
> date is the date of the first dvipost release that works.
It is not depending on the dvipost version, but on the teTeX version (i.e.
dvips, according to E. Frühstück). I think we can just demnd teTeX 2.x to
be installed (otherwise people just don't see the ct marks in the output).
>> This is definitely the right solution. Getting rid of special casing
>> is always better.
>>
>> I like that.
>
> Me too.
Me as well. I'll post a patch later this week.
Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen I tested the attached patch on my home machine now quite
Juergen intensely and discovered no problems. Change tracking works
Juergen fine, beamer works fine. With the new code
Juergen (\PassOptionsToPackage), even change tracking within beamer
Juergen works!
I am not sure I understand. I thought the problem was that beamer
loads xcolor by itself. In this case, what is the difference between
\PassOptionToPackage{usenames}{color}
\usepackage{color}
and
\usepackage[usenames]{color}
And what is the result? Is the usenames option really active when
using beamer+changes? Why?
I am sorry to ask again, it may be I did not follow this thread
closely enough.
JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote:
I am not sure I understand. I thought the problem was that beamer
loads xcolor by itself. In this case, what is the difference between
\PassOptionToPackage{usenames}{color}
\usepackage{color}
and
\usepackage[usenames]{color}
Beamer apparently loads color. Either color and xcolor are loaded by beamer,
or xcolor pretends that it is color.
Anyway, here's the relevant LaTeX error:
The package color has already been loaded with options:
[pdftex]
There has now been an attempt to load it with options
[usenames]
Adding the global options:
pdftex,usenames
to your \documentclass declaration may fix this.
Try typing return to proceed.
The difference is, of course, that the new version does not lead to option
conflicts.
And what is the result? Is the usenames option really active when
using beamer+changes? Why?
I'm not sure either. However, at least change tracking marks are visible in
the DVI output of beamer documents.* To be sure that usenames is active,
\PassOptionsToPackage would have to be placed before \documentclass.
Something for post-1.4.0 IMHO.
*My theory is that usenames is not active in Beamer. But usenames is declared
obsolete in the xcolor docs. So obviously that option is not needed anymore
when using dvipost together with xcolor.
I am sorry to ask again, it may be I did not follow this thread
closely enough.
Feel free to ask further questions.
Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> I tested the attached patch on my home machine now quite
Juergen> intensely and discovered no problems. Change tracking works
Juergen> fine, beamer works fine. With the new code
Juergen> (\PassOptionsToPackage), even change tracking within beamer
Juergen> works!
I am not sure I understand. I thought the problem was that beamer
loads xcolor by itself. In this case, what is the difference between
\PassOptionToPackage{usenames}{color}
\usepackage{color}
and
\usepackage[usenames]{color}
And what is the result? Is the usenames option really active when
using beamer+changes? Why?
I am sorry to ask again, it may be I did not follow this thread
closely enough.
JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote:
> I am not sure I understand. I thought the problem was that beamer
> loads xcolor by itself. In this case, what is the difference between
> \PassOptionToPackage{usenames}{color}
> \usepackage{color}
> and
> \usepackage[usenames]{color}
Beamer apparently loads color. Either color and xcolor are loaded by beamer,
or xcolor pretends that it is color.
Anyway, here's the relevant LaTeX error:
The package color has already been loaded with options:
[pdftex]
There has now been an attempt to load it with options
[usenames]
Adding the global options:
pdftex,usenames
to your \documentclass declaration may fix this.
Try typingto proceed.
The difference is, of course, that the new version does not lead to option
conflicts.
> And what is the result? Is the usenames option really active when
> using beamer+changes? Why?
I'm not sure either. However, at least change tracking marks are visible in
the DVI output of beamer documents.* To be sure that usenames is active,
\PassOptionsToPackage would have to be placed before \documentclass.
Something for post-1.4.0 IMHO.
*My theory is that usenames is not active in Beamer. But usenames is declared
obsolete in the xcolor docs. So obviously that option is not needed anymore
when using dvipost together with xcolor.
> I am sorry to ask again, it may be I did not follow this thread
> closely enough.
Feel free to ask further questions.
Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote:
Did you check that change tracking/dvipost still works in other classes?
If yes, I vote to include your patch.
Yes, I tested within limits. I am away from my home machine and working
with a devel version from Kayvan atm. I'll test more intensively when I'm
back home.
I tested the attached patch on my home machine now quite intensely and
discovered no problems. Change tracking works fine, beamer works fine. With
the new code (\PassOptionsToPackage), even change tracking within beamer
works!
Can I commit this, please?
Jürgen
Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.119
diff -p -u -r1.119 LaTeXFeatures.C
--- src/LaTeXFeatures.C 11 Jun 2005 11:02:22 - 1.119
+++ src/LaTeXFeatures.C 21 Jan 2006 12:00:16 -
@@ -281,13 +281,13 @@ string const LaTeXFeatures::getPackages(
// color.sty
if (isRequired(color)) {
- if (params_.graphicsDriver == default)
- packages \\usepackage[usenames]{color}\n;
- else
- packages \\usepackage[
+ if (params_.graphicsDriver != default)
+ packages \\PassOptionsToPackage{
params_.graphicsDriver
- ,usenames
- ]{color}\n;
+ }{color}\n;
+ if (isRequired(dvipost))
+ packages \\PassOptionsToPackage{usenames}{color}\n;
+ packages \\usepackage{color}\n;
}
// makeidx.sty
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote:
> > Did you check that change tracking/dvipost still works in other classes?
> > If yes, I vote to include your patch.
>
> Yes, I tested within limits. I am away from my home machine and working
> with a devel version from Kayvan atm. I'll test more intensively when I'm
> back home.
I tested the attached patch on my home machine now quite intensely and
discovered no problems. Change tracking works fine, beamer works fine. With
the new code (\PassOptionsToPackage), even change tracking within beamer
works!
Can I commit this, please?
Jürgen
Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.119
diff -p -u -r1.119 LaTeXFeatures.C
--- src/LaTeXFeatures.C 11 Jun 2005 11:02:22 - 1.119
+++ src/LaTeXFeatures.C 21 Jan 2006 12:00:16 -
@@ -281,13 +281,13 @@ string const LaTeXFeatures::getPackages(
// color.sty
if (isRequired("color")) {
- if (params_.graphicsDriver == "default")
- packages << "\\usepackage[usenames]{color}\n";
- else
- packages << "\\usepackage["
+ if (params_.graphicsDriver != "default")
+ packages << "\\PassOptionsToPackage{"
<< params_.graphicsDriver
- << ",usenames"
- << "]{color}\n";
+ << "}{color}\n";
+ if (isRequired("dvipost"))
+ packages << "\\PassOptionsToPackage{usenames}{color}\n";
+ packages << "\\usepackage{color}\n";
}
// makeidx.sty
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Georg Baum wrote: Did you check that change tracking/dvipost still works in other classes? If yes, I vote to include your patch. Yes, I tested within limits. I am away from my home machine and working with a devel version from Kayvan atm. I'll test more intensively when I'm back home. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen How about the attached? Makes the code even simpler. I did not follow all the details of this thread, but why don't we just add options like 'usenames' to \documentclass options? JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote: I did not follow all the details of this thread, but why don't we just add options like 'usenames' to \documentclass options? I'm not sure if we should do this generally. After all, it is possible that different packages use options of the same name. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Jean-Marc Lasgouttes wrote: I did not follow all the details of this thread, but why don't we just add options like 'usenames' to \documentclass options? Juergen I'm not sure if we should do this generally. I agree with that. Juergen After all, it is possible that different packages use options Juergen of the same name. Sure, but in this case I suspect it is the cleanest way to fix the bug (am I wrong?). Concerning having a ProvidesColor 1, what I would like to do (maybe in 1.4.x, we'll see) is to implement instead a Provides feature that would tell LaTeXFeatures that feature is available. That would be both simpler and more powerful than what we have now. JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote: Herbert Voss wrote: Isn't RequirePackage for packages and classes and usepackage for the preamble (this is what I read in the documents)? yes and no ... Why yes, why no? - take care of some formal structure - makes life easier in a big document with tons of loaded packages How about the attached? Makes the code even simpler. I forget the order of loading packages. Was ist first LyX and then user or vice versa? \PassOptionsToPackage makes only sense when the package was not loaded. WHich is the reason why these macros are always placed befor or after \documentclass. First LyX, then user (except babel, which is loaded at the very end). However, in the case of beamer, that is -- as the document class -- loaded first. I think, for the actual beamer problem, the proposed solution is sufficient. For later, I'd propose to add a method to LaTeXFeatures.C that takes care of all options and passes them to the corresponding packages with \PassOptionsToPackage (at the moment, we have lots of packages calls which pass the options as optional arguments). Those macros will all be written immediately after \documentclass. We could combine it with \ProvidesPackage. When a documentclass already loads a package, we could then pass the options directly to the documentclass. Does this make sense? not really, because there exists some packages, which have the same option name, but with a different meaning. Passing it via \documentclass can cause problems. \PassOptionsToPackage is the save way, except the traditional options like draft, a4paper, ... which are used by all packages and classes in the same way. Herbert
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote: Sure, but in this case I suspect it is the cleanest way to fix the bug (am I wrong?). I'm not sure. After all, we do _not_ want usenames in other cases than dvipost. Also I'm not sure if usenames is mutually exclusive with other color options that might be needed by other packages. Concerning having a ProvidesColor 1, what I would like to do (maybe in 1.4.x, we'll see) is to implement instead a Provides feature that would tell LaTeXFeatures that feature is available. That would be both simpler and more powerful than what we have now. I thought about something like this, too. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Herbert Voss wrote:
not really, because there exists some packages, which have the
same option name, but with a different meaning. Passing it via
\documentclass can cause problems.
\PassOptionsToPackage is the save way, except the traditional options
like draft, a4paper, ... which are used by all packages and classes
in the same way.
Yes, I thought about it as last exit solution (only if we know that the
package in question has already been loaded by the class).
What is, for example, if a document class has
\RequirePackage{color}
and we add after \documentclass
\PassOptionsToPackage{usenames}{color}
\usepackage{color}
Will this work?
Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote: I'm not sure. After all, we do _not_ want usenames in other cases than dvipost. Also I'm not sure if usenames is mutually exclusive with other color options that might be needed by other packages. Y'know, what this smacks of is clever behaviour which is all very good but I think that some future package manager should give the user the ability to explicitly turn on and off the options to a package. Wasn't a package manager something that was interesting you at one time, Jürgen? -- Angus
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote:
Herbert Voss wrote:
not really, because there exists some packages, which have the
same option name, but with a different meaning. Passing it via
\documentclass can cause problems.
\PassOptionsToPackage is the save way, except the traditional options
like draft, a4paper, ... which are used by all packages and classes
in the same way.
Yes, I thought about it as last exit solution (only if we know that the
package in question has already been loaded by the class).
What is, for example, if a document class has
\RequirePackage{color}
and we add after \documentclass
\PassOptionsToPackage{usenames}{color}
\usepackage{color}
Will this work?
yes, but only when the documentclass has itself a \PassOptionsToPackage
for its own needed options:
This is save:
\PassOptionsToPackage{usenames}{color}
\documentclass
\usepackage{color}
Herbert
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Y'know, what this smacks of is clever behaviour Yes, this is a problem. Angus which is all very good but I think that some future package Angus manager should give the user the ability to explicitly turn on Angus and off the options to a package. No, in this case the user should not have to know about subtleties of color and xcolor packages when using beamer with dvipost. JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Angus Leeming wrote: Y'know, what this smacks of is clever behaviour which is all very good but I think that some future package manager should give the user the ability to explicitly turn on and off the options to a package. Wasn't a package manager something that was interesting you at one time, Jürgen? Sure. My aim now is really to get an as clean as possible, yet easy fix for the beamer conflict, which is likely to cause no other severe conflicts. I still think my solution is the best for this now. Anything else needs intensive cognitive care post 1.4.0. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Herbert Voss wrote:
This is save:
\PassOptionsToPackage{usenames}{color}
\documentclass
\usepackage{color}
I see. Good to know.
Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Georg Baum wrote: > Did you check that change tracking/dvipost still works in other classes? > If yes, I vote to include your patch. Yes, I tested within limits. I am away from my home machine and working with a devel version from Kayvan atm. I'll test more intensively when I'm back home. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> How about the attached? Makes the code even simpler. I did not follow all the details of this thread, but why don't we just add options like 'usenames' to \documentclass options? JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote: > I did not follow all the details of this thread, but why don't we just > add options like 'usenames' to \documentclass options? I'm not sure if we should do this generally. After all, it is possible that different packages use options of the same name. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> I did not follow all the details of this thread, but why don't we >> just add options like 'usenames' to \documentclass options? Juergen> I'm not sure if we should do this generally. I agree with that. Juergen> After all, it is possible that different packages use options Juergen> of the same name. Sure, but in this case I suspect it is the cleanest way to fix the bug (am I wrong?). Concerning having a "ProvidesColor 1", what I would like to do (maybe in 1.4.x, we'll see) is to implement instead a "Provides " that would tell LaTeXFeatures that is available. That would be both simpler and more powerful than what we have now. JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote: > Herbert Voss wrote: > >>> Isn't RequirePackage for packages and classes and usepackage for the >>> preamble (this is what I read in the documents)? >> >> yes and no ... > > Why yes, why no? - take care of some formal structure - makes life easier in a big document with tons of loaded packages >>> How about the attached? Makes the code even simpler. >> >> I forget the order of loading packages. Was ist first LyX and >> then user or vice versa? \PassOptionsToPackage makes only >> sense when the package was not loaded. WHich is the reason >> why these macros are always placed befor or after >> \documentclass. > > First LyX, then user (except babel, which is loaded at the very end). > However, in the case of beamer, that is -- as the document class -- loaded > first. I think, for the actual beamer problem, the proposed solution is > sufficient. > > For later, I'd propose to add a method to LaTeXFeatures.C that takes care > of all options and passes them to the corresponding packages with > \PassOptionsToPackage (at the moment, we have lots of packages calls which > pass the options as optional arguments). Those macros will all be written > immediately after \documentclass. We could combine it with > \ProvidesPackage. When a documentclass already loads a package, we could > then pass the options directly to the documentclass. > Does this make sense? not really, because there exists some packages, which have the same option name, but with a different meaning. Passing it via \documentclass can cause problems. \PassOptionsToPackage is the save way, except the traditional options like draft, a4paper, ... which are used by all packages and classes in the same way. Herbert
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Jean-Marc Lasgouttes wrote: > Sure, but in this case I suspect it is the cleanest way to fix the bug > (am I wrong?). I'm not sure. After all, we do _not_ want usenames in other cases than dvipost. Also I'm not sure if usenames is mutually exclusive with other color options that might be needed by other packages. > Concerning having a "ProvidesColor 1", what I would like to do (maybe > in 1.4.x, we'll see) is to implement instead a "Provides " > that would tell LaTeXFeatures that is available. That would > be both simpler and more powerful than what we have now. I thought about something like this, too. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Herbert Voss wrote:
> not really, because there exists some packages, which have the
> same option name, but with a different meaning. Passing it via
> \documentclass can cause problems.
> \PassOptionsToPackage is the save way, except the traditional options
> like draft, a4paper, ... which are used by all packages and classes
> in the same way.
Yes, I thought about it as "last exit" solution (only if we know that the
package in question has already been loaded by the class).
What is, for example, if a document class has
\RequirePackage{color}
and we add after \documentclass
\PassOptionsToPackage{usenames}{color}
\usepackage{color}
Will this work?
Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote: > I'm not sure. After all, we do _not_ want usenames in other cases than > dvipost. Also I'm not sure if usenames is mutually exclusive with other > color options that might be needed by other packages. Y'know, what this smacks of is "clever" behaviour which is all very good but I think that some future "package manager" should give the user the ability to explicitly turn on and off the options to a package. Wasn't a package manager something that was interesting you at one time, Jürgen? -- Angus
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote:
> Herbert Voss wrote:
>
>> not really, because there exists some packages, which have the
>> same option name, but with a different meaning. Passing it via
>> \documentclass can cause problems.
>> \PassOptionsToPackage is the save way, except the traditional options
>> like draft, a4paper, ... which are used by all packages and classes
>> in the same way.
>
> Yes, I thought about it as "last exit" solution (only if we know that the
> package in question has already been loaded by the class).
> What is, for example, if a document class has
> \RequirePackage{color}
>
> and we add after \documentclass
> \PassOptionsToPackage{usenames}{color}
> \usepackage{color}
>
> Will this work?
yes, but only when the documentclass has itself a \PassOptionsToPackage
for its own needed options:
This is save:
\PassOptionsToPackage{usenames}{color}
\documentclass
\usepackage{color}
Herbert
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Y'know, what this smacks of is "clever" behaviour Yes, this is a problem. Angus> which is all very good but I think that some future "package Angus> manager" should give the user the ability to explicitly turn on Angus> and off the options to a package. No, in this case the user should not have to know about subtleties of color and xcolor packages when using beamer with dvipost. JMarc
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Angus Leeming wrote: > Y'know, what this smacks of is "clever" behaviour which is all very good > but I think that some future "package manager" should give the user the > ability to explicitly turn on and off the options to a package. > > Wasn't a package manager something that was interesting you at one time, > Jürgen? Sure. My aim now is really to get an as clean as possible, yet easy fix for the beamer conflict, which is likely to cause no other severe conflicts. I still think my solution is the best for this now. Anything else needs intensive cognitive care post 1.4.0. Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Herbert Voss wrote:
> This is save:
> \PassOptionsToPackage{usenames}{color}
> \documentclass
> \usepackage{color}
I see. Good to know.
Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote:
if (isRequired(color)) {
if (params_.graphicsDriver == default)
- packages \\usepackage[usenames]{color}\n;
- else
+ if (isRequired(dvipost))
+ packages \\usepackage[usenames]{color}\n;
+ else
+ packages \\usepackage{color}\n;
+ else {
-- this is not user friendly _and_ can give errors when
another package needs color with anotehr option.
-- you should load xcolor with
\IfFileExists{xcolor.sty}{%
\PassOptionsToPackage{dvipsnames}{xcolor}
\RequirePackage{xcolor}}{%
\PassOptionsToPackage{usenames}{color}
\RequirePackage{color}}
packages \\usepackage[
- params_.graphicsDriver
- ,usenames
- ]{color}\n;
+ params_.graphicsDriver;
+ if (isRequired(dvipost))
+ packages ,usenames;
+ packages ]{color}\n;
+ }
\PassOptionsToPackage should _always_ be used instead of the above.
Herbert
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Herbert Voss wrote:
-- this is not user friendly and can give errors when
another package needs color with anotehr option.
OK.
-- you should load xcolor with
I guess xcolor support is not an issue for 1.4.0 (I agree that we should add
it to forthcoming versions, though). This is just to restore the status of
1.3, i.e. get beamer working again.
\IfFileExists{xcolor.sty}{%
\PassOptionsToPackage{dvipsnames}{xcolor}
\RequirePackage{xcolor}}{%
Isn't RequirePackage for packages and classes and usepackage for the
preamble (this is what I read in the documents)?
How about the attached? Makes the code even simpler.
Jürgen
--- LaTeXFeatures.C.old 2006-01-17 21:27:47.0 +0100
+++ LaTeXFeatures.C 2006-01-17 23:00:36.0 +0100
@@ -281,13 +281,13 @@ string const LaTeXFeatures::getPackages(
// color.sty
if (isRequired(color)) {
- if (params_.graphicsDriver == default)
- packages \\usepackage[usenames]{color}\n;
- else
- packages \\usepackage[
+ if (params_.graphicsDriver != default)
+ packages \\PassOptionsToPackage{
params_.graphicsDriver
- ,usenames
- ]{color}\n;
+ }{color}\n;
+ if (isRequired(dvipost))
+ packages \\PassOptionsToPackage{usenames}{color}\n;
+ packages \\usepackage{color}\n;
}
// makeidx.sty
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote: Isn't RequirePackage for packages and classes and usepackage for the preamble (this is what I read in the documents)? yes and no ... How about the attached? Makes the code even simpler. I forget the order of loading packages. Was ist first LyX and then user or vice versa? \PassOptionsToPackage makes only sense when the package was not loaded. WHich is the reason why these macros are always placed befor or after \documentclass. Herbert
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Herbert Voss wrote: Isn't RequirePackage for packages and classes and usepackage for the preamble (this is what I read in the documents)? yes and no ... Why yes, why no? How about the attached? Makes the code even simpler. I forget the order of loading packages. Was ist first LyX and then user or vice versa? \PassOptionsToPackage makes only sense when the package was not loaded. WHich is the reason why these macros are always placed befor or after \documentclass. First LyX, then user (except babel, which is loaded at the very end). However, in the case of beamer, that is -- as the document class -- loaded first. I think, for the actual beamer problem, the proposed solution is sufficient. For later, I'd propose to add a method to LaTeXFeatures.C that takes care of all options and passes them to the corresponding packages with \PassOptionsToPackage (at the moment, we have lots of packages calls which pass the options as optional arguments). Those macros will all be written immediately after \documentclass. We could combine it with \ProvidesPackage. When a documentclass already loads a package, we could then pass the options directly to the documentclass. Does this make sense? Jürgen
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote:
if (isRequired("color")) {
if (params_.graphicsDriver == "default")
- packages << "\\usepackage[usenames]{color}\n";
- else
+ if (isRequired("dvipost"))
+ packages << "\\usepackage[usenames]{color}\n";
+ else
+ packages << "\\usepackage{color}\n";
+ else {
-- this is not user friendly _and_ can give errors when
another package needs color with anotehr option.
-- you should load xcolor with
\IfFileExists{xcolor.sty}{%
\PassOptionsToPackage{dvipsnames}{xcolor}
\RequirePackage{xcolor}}{%
\PassOptionsToPackage{usenames}{color}
\RequirePackage{color}}
packages << "\\usepackage["
-<< params_.graphicsDriver
-<< ",usenames"
-<< "]{color}\n";
+<< params_.graphicsDriver;
+ if (isRequired("dvipost"))
+ packages << ",usenames";
+ packages << "]{color}\n";
+ }
\PassOptionsToPackage should _always_ be used instead of the above.
Herbert
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Herbert Voss wrote:
> -- this is not user friendly and can give errors when
> another package needs color with anotehr option.
OK.
> -- you should load xcolor with
I guess xcolor support is not an issue for 1.4.0 (I agree that we should add
it to forthcoming versions, though). This is just to restore the status of
1.3, i.e. get beamer working again.
> \IfFileExists{xcolor.sty}{%
> \PassOptionsToPackage{dvipsnames}{xcolor}
> \RequirePackage{xcolor}}{%
Isn't RequirePackage for packages and classes and usepackage for the
preamble (this is what I read in the documents)?
How about the attached? Makes the code even simpler.
Jürgen
--- LaTeXFeatures.C.old 2006-01-17 21:27:47.0 +0100
+++ LaTeXFeatures.C 2006-01-17 23:00:36.0 +0100
@@ -281,13 +281,13 @@ string const LaTeXFeatures::getPackages(
// color.sty
if (isRequired("color")) {
- if (params_.graphicsDriver == "default")
- packages << "\\usepackage[usenames]{color}\n";
- else
- packages << "\\usepackage["
+ if (params_.graphicsDriver != "default")
+ packages << "\\PassOptionsToPackage{"
<< params_.graphicsDriver
- << ",usenames"
- << "]{color}\n";
+ << "}{color}\n";
+ if (isRequired("dvipost"))
+ packages << "\\PassOptionsToPackage{usenames}{color}\n";
+ packages << "\\usepackage{color}\n";
}
// makeidx.sty
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Juergen Spitzmueller wrote: Isn't RequirePackage for packages and classes and usepackage for the preamble (this is what I read in the documents)? yes and no ... How about the attached? Makes the code even simpler. I forget the order of loading packages. Was ist first LyX and then user or vice versa? \PassOptionsToPackage makes only sense when the package was not loaded. WHich is the reason why these macros are always placed befor or after \documentclass. Herbert
Re: About bug 2169: Inserted \usepackage[usenames]{color} clashes with beamer/xcolor
Herbert Voss wrote: >> Isn't RequirePackage for packages and classes and usepackage for the >> preamble (this is what I read in the documents)? > > yes and no ... Why yes, why no? >> How about the attached? Makes the code even simpler. > > I forget the order of loading packages. Was ist first LyX and > then user or vice versa? \PassOptionsToPackage makes only > sense when the package was not loaded. WHich is the reason > why these macros are always placed befor or after > \documentclass. First LyX, then user (except babel, which is loaded at the very end). However, in the case of beamer, that is -- as the document class -- loaded first. I think, for the actual beamer problem, the proposed solution is sufficient. For later, I'd propose to add a method to LaTeXFeatures.C that takes care of all options and passes them to the corresponding packages with \PassOptionsToPackage (at the moment, we have lots of packages calls which pass the options as optional arguments). Those macros will all be written immediately after \documentclass. We could combine it with \ProvidesPackage. When a documentclass already loads a package, we could then pass the options directly to the documentclass. Does this make sense? Jürgen
