Ah, yes, true.

The only other option I can see, if the "declare options later" method
won't work, is to mess with the compilation process itself, so that you
can remove the offending lines that LyX inserts. If you look under Tools
> Preferences > Converters, you'll see the command LyX is using to
"convert" LaTeX to DVI, say. (Yes, unfortunately, you would have several
of these to change.) The idea would be to write a little filter that
would strip out those lines before calling latex. So you'd have a script
that looked roughly like:

filterlyx $1
latex $1

Then we can arrange to call this script instead of whatever LyX is
calling to do the LaTeX to DVI conversion.

Obviously, an enhancement request is certainly in order here. I suppose
the request would be for there to be a way to suppress the inclusion of
these sorts of packages.

Richard

Kevin Paunovic wrote:
> Aye aye, but this becomes tweaky when LyX declares a "nude" package
> (without any option) and you declare, after that, the same package but
> this time with options.
> Ex: \usepackage{graphicx}
> \usepackage[dvips]{graphicx}
>
> This causes Latex compiler hauling that graphicx was already loaded
> (this is ok), but without the same options (this bugs). Most packages
> give commands to declare options after the package is loaded
> (something like \graphicx{dvips}, etc. geometry package is good at
> that :) but sometimes you may find no answer.
>
>
> On Feb 6, 2007, at 5:07 PM, Richard Heck wrote:
>
>>
>> The way to handle this, I'd think, is to use some kind of conditional.
>> LyX adds its material BEFORE your custom preamble stuff gets included.
>> So you basically just need to check for the existence of something you
>> know LyX will have done. LyX pretty much always to use inputenc.sty, so
>> perhaps checking for \inputencoding via
>> \ifx\inputencoding\undefined
>> would work.
>>
>> It might be worth filing an enhancement request, asking that LyX should
>> define \iflyx or something.
>>
>> Richard
>>
>> Kevin Paunovic wrote:
>>> I use LyX as a structured content editor. I mean, I need people write
>>> the documentation of software manuals in a structured language and, as
>>> they fear xml, I proposed LyX. So I wrote a .sty that contains
>>> everything we need to generate manuals and documentation. This
>>> includes commands Latex like:
>>>
>>> ...
>>> \RequirePackage[latin1]{inputenc}
>>> \RequirePackage[T1]{fontenc}
>>> \RequirePackage{lmodern}
>>> \RequirePackage[frenchb,english]{babel}
>>> \ifpdf
>>> \RequirePackage[pdftex]{graphicx}
>>> \RequirePackage[cmyk,fixpdftex,pdftex]{xcolor}
>>> \else
>>> \RequirePackage[dvips]{graphicx}
>>> \RequirePackage[cmyk,dvips]{xcolor}
>>> \fi
>>> ...
>>>
>>> The problem now is that LyX automatically adds things like:
>>> \usepackage[T1]{fontenc}
>>> \usepackage[latin1]{inputenc}
>>> \usepackage{graphicx}
>>> \usepackage{babel}
>>>
>>> so, as you might expect, this leads to crashes at compilation.
>>>
>>> How to get rid of all those things LyX adds?
>>>
>>> PS: Please note that I find this feature (automatically adding common
>>> packages) very great. I know I use LyX a strange way and I shouldn't
>>> include everything in a .sty file, but you know, people I work with
>>> are far more strange than this ;)
>>
>>
>> --==================================================================
>> Richard G Heck, Jr
>> Professor of Philosophy
>> Brown University
>> http://bobjweil.com/heck/
>> ==================================================================
>> Get my public key from http://sks.keyserver.penguin.de
>> Hash: 0x1DE91F1E66FFBDEC
>> Learn how to sign your email using Thunderbird and GnuPG at:
>> http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
>>
>


-- 
==================================================================
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://bobjweil.com/heck/
==================================================================
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Reply via email to