Hello Alex, > I propose one of two > solutions: isn't a way to get layout files automatically from cls > file definitions, if this is too overwhelming I can handle with just > the basics and then add manually the rest for the first glance (a > python script would be nice, suggested name "cls2layout.py"); second > solution could be that lyx can actually read the cls file as an > option to the layout file, this is not in lyx philosophy but why > not? It would be helpful in some specific cases like this which is > used a lot. Probably this is solved someway or someone has already > found a solution so it would be nice if it is published here, I'm > open at suggestions.
This would be extremely difficult to do. Realize that most non-trivial
packages do not rely on plain LaTeX, but rather implement large amounts
of their functionality in plain TeX and things are much messier down
there.
Just consider:
1.- it simply is not the case that you can just parse out
\newcommand, \renewcommand and newenvironmennt definitions and you
are fine. In fact, most of the time you are not. What you need to
consider are all the \def definitions, but that's not the way to do
it. Perhaps for the default LaTeX packages yes, but not the custom
ones of journals and various publishers. In fact, many of those I
saw so far were implemented so that they work for the publisher,
they are not meant to tinker with too much.
2.- TeX (and hence LaTeX) does not facilitate specification of a public
interface of a package. In fact everything (i.e., every symbol
defined in any package) is public - hence all the issues with
namespace clashes between packages. So there's no easy way to say
what should be articulated in the resulting layout.
3.- for many non-trivial packages, the parsing of arguments (e.g.,
starred environments) is done dynamically. Without interpreting the
underlying TeX code you wouldn't be able to find out what the
arguments of a command, nor their semantics and layout ([] vs. {})
should be.
... and we did not dive yet into all the options, and configuration
directives various packages enable (e.g., KOMA packages are very
rich and complex in this respect).
All this could be helped by having package implementors annotated
commands, but well, it's already too late (30+ years too late?) to
complain about that one, right? We have thousands of packages existing
already. Another idea might me to parse the cls file and then decide
what is important and how it is used by searching the web for tex files
with that document class and automatically extract/learn from those what
is the package interface. Well, good luck with that one...
So to sum up: in my opinion, manual layout file creation is the
easiest and most reliable method to rely upon.
My 2 cents.
Best,
Peter.
--
Peter Novak, [email protected], http://peter.aronde.net/
signature.asc
Description: Digital signature
