Re: LaTeXConf
On Mon, 26 Apr 1999, Martin Vermeer wrote: > [...] > ARRae> Certainly is comprehensive. AFA the interface is concerned it really is > > too cluttered and a tabbed folder would be a much less complex interface. > > But as you say, it is only preliminary. > > tcl/tk unfortunately has no tabbed dialog boxes. It would certainly look > better. Ahhh, it must have been tix(?) or one of those extra toolkits that has tabbed boxes. > tcl/tk is a great language for rapid prototyping. Once neoprene/latexconf > stabilizes, translation to perl/tk or even gtk should not be very difficult. > But not yet in the present, experimental phase. Python/tk might be a better option particularly in light of the fact that KDE has settled on Python as their scripting language of choice. But there's nothing wrong with tcl/tk. Allan. (ARRae)
Re: LaTeXConf
On Mon, Apr 26, 1999 at 02:47:58PM +0400, Martin Vermeer wrote: > [...] > > > Any chance of translating this into Perl so Amir can have something else > > to do? ;-) > > My impression was that Amir had no particular difficulty finding ways of > occupying himself ;-) Of course perl/tk would be great for this. Unfortunately > I don't know it and taking off time to learn it would slow me down too much. > > tcl/tk is a great language for rapid prototyping. Once neoprene/latexconf > stabilizes, translation to perl/tk or even gtk should not be very difficult. > But not yet in the present, experimental phase. Yes, I can find things to do with my time. Also, I've never done tk. -Amir
Re: LaTeXConf
[...] ARRae> Certainly is comprehensive. AFA the interface is concerned it really is > too cluttered and a tabbed folder would be a much less complex interface. > But as you say, it is only preliminary. tcl/tk unfortunately has no tabbed dialog boxes. It would certainly look better. > Any chance of translating this into Perl so Amir can have something else > to do? ;-) My impression was that Amir had no particular difficulty finding ways of occupying himself ;-) Of course perl/tk would be great for this. Unfortunately I don't know it and taking off time to learn it would slow me down too much. tcl/tk is a great language for rapid prototyping. Once neoprene/latexconf stabilizes, translation to perl/tk or even gtk should not be very difficult. But not yet in the present, experimental phase. Martin
Re: LaTeXConf
On Sat, 17 Apr 1999, Martin Vermeer wrote: > A very early implementation of LaTeXConf can be found at > > http://www.netby.net/Oest/Europa-Alle/vermeer/lcf.tcl > > with the help file as lcf.help in the same dir. (The same place also > holds the neoprene stuff.) > > All VERY preliminary. But you can get an idea of what I have in mind. > (And just in case I get hit by a truck tomorrow ;-) Certainly is comprehensive. AFA the interface is concerned it really is too cluttered and a tabbed folder would be a much less complex interface. But as you say, it is only preliminary. Any chance of translating this into Perl so Amir can have something else to do? ;-) You do good work. Keep it up, Allan. (ARRae)
LaTeXConf
A very early implementation of LaTeXConf can be found at http://www.netby.net/Oest/Europa-Alle/vermeer/lcf.tcl with the help file as lcf.help in the same dir. (The same place also holds the neoprene stuff.) All VERY preliminary. But you can get an idea of what I have in mind. (And just in case I get hit by a truck tomorrow ;-) Martin
`latexconf' taking shape
It may interest you to know that I have decided to see if the`latexconf'
idea mentioned here some months ago has the potential of being realized.
What I am currently doing is create a set of LaTeX classes (based on the
base classes, and backward compatible with them) that are massively
parametrized (i.e. anything you might want to change has a variable/command
name/counter/if attached to it). What I've done so far does not appear to
noticebly affect performance.
What I am also doing is moving some generally important add-on package
functionality into this package. Stuff (e.g. hanging captions and the
like, and some things found in Komascript and the Dutch classes and in
titlesec and the upcoming titletoc) that ought to be by its nature in the
base package, like it is in most word processors. Bloatware, you may say,
but situation now is a little bit different than when fifty scientists were
sharing a single VAX780!
Anyway, I am making this up as I go along; once finished, the idea is to
create a graphical control utility (in tcl/tk or whatever) to be able to
configure all these parameters in a sensible way. Of course this could be done
directly from within LyX; but I think this facility will be useful independent
of LyX. Derfor I think the only thing LyX will have to do is (1) have a menu
item for calling this config utility, (2) have it edit myfile.lcf, if the
document itself is myfile.lyx, and (3) insert \input{myfile.lcf} into
the preamble. Of course provided the LyX configure finds it. In due time!
All this is theory still, as I am busy becoming a TeX/LaTeX guru (fascinating
language, but tricky ;-). Look at the current status (below), remembering
that this is still pre-cambrian alpha. I am doing this at my own pace when
things are unusually hectic at my job, and will not get anywhere probably
before summer, if not autumn. It's mainly the philosophy behind it that might
currently interest you.
Have a look:
htpp://www.netby.net/Oest/Europa-Alle/vermeer/neoprene.dtx (and .ins)
Martin
Re: alfanum.cls, etc. (was: Re: PR-1.0.3... and latexconf)
Thanks for all this friendly feedback,
On Fri, 12 Feb 1999 13:59:16 +1000 (GMT+1000), Allan Rae wrote:
>On Thu, 11 Feb 1999, Arnd Hanses wrote:
>> Also I'm looking forward to receive some bug reports, suggestions,
>> fixes, etc. in order to improve this.
>
>One bug I fixed in LyX (after 1.0.0) that your alfanum.layout triggered
>was reading (and ignoring of) carriage-returns ('\r') which would crash
>LyX when reading the alignment possibilities from the layout file.
Yes, this is a well known, all time favourite problem of most programs
coming from the UN*X world (LyX would not be an exeception here), which
causes constant grief when any cross platform issues occur (Xfree/2 faq
has a whole paragraph on this issue). It seems there is no automatic
switch for that in compilers and or autoconf/imake. There are certainly
several thousand programs which would profit from such an automatic
switch. I'm wondering if somebody tired of fixing this by hand has
prepared an automatical method?
>So you may want to ensure that the next release doesn't have any '\r's in
>it at all just to be sure you don't trigger any crashes in LyX versions
><=1.0.0 (I did send an email about this previously but I think its one of
>the ones that disappeared into the ether).
As I was generally aware of such problems (I did include a warning
about possible crashes, just in case), I did test the copies before
mailing. And I can assure, the CC of the alphanum.zip in my 'mail sent'
archive folder does not contain such evil things, so I do assume this
should also be true for the one I sent.
But, damn, how does it come then and what more can I do to prevent such
effects. I contemplated a while and I found that certain
archivers/unarchivers/frontends produce unexpected effects when cross
platform archives (I archived on OS/2) are involved. Some of them do
more or less silent conversions (or 'fixes') of text files according to
their authors preferences. Even those with the same version number
(only date changed) differ in their behaviour. Most prominently some of
the more recent InfoZip releases are renowned.
If anybody has an idea, just let me know.
>> What I cannot do is changing the
>> LyX code (I'm not a programmer) so that it looks less ugly in LyX (Xdvi
>> is perfect). I definitely would like to see the numbers in LyX, too,
>> before finally releasing it. Otherwise it would not be WYSIWYM, I
>> think, i.e. not really working together with LyX.
>
>Don't worry about the numbering. It's WYSIWYM to have all arabic
>numbering and WYSIWYG to have correct numbering.
>IEEEtran also has non-arabic numbering schemes and for the 1.0 series its
>also stuck with arabic-only numbering onscreen in LyX. This will change
>in 1.1.x so don't worry about it. Just add a small note to that effect in
>the documentation for alfanum.
>
No, you will not find arabic numbering on the LyX screen in the layouts
I hacked; 2 reasons for that:
1) LaTeX standard classes (and thus the LyX screen) provide only 5
sectioning levels -which is ridiculous at least for the work I must
do-, finding them on the screen in my 12 level layout would be too
puzzling for me; for others too, perhaps. So you will find relative
levels compared to the previous one (similar to the method the original
LaTeX 'alphanumeric.sty' in
CTAN/macro/Latex2e/contrib/supported/jura/
uses:
TOC entry on the same level, sublevel, uplevel.
2) After rereading an old paper containing arabic numbering (on _many_
levels) I severely began to hate this I would say there is some new
kind of allergy involved...
>
>> On Tue, 02 Feb 1999 11:57:28 +0200, Martin Vermeer wrote:
>>
>> >looks fascinating. ...
>> >What fascinates me is your definition of greek letters for section titles,
>> >and the massive number of section levels. I might want to pinch that :-)
>>
>> Martin,
>>
>> what does 'pinch' mean here? Did it work?
>
>pinch is slang for steal, ie. if you pinch something then you stole it.
>(other interesting slang terms for steal: snavel, nick, lift)
Yes, I'm really feeling like becoming an expert for cyber _argot_ now,
with all those helpful souls around...;)
What about introducing a new word from German into Cyberia which is
nice, too:
'klemmen'
It would be _lift_ as well as block, fix, attach...
>> Is it possible to 'pinch' it together with 1.0.1 (could be another new
>> feature), or should we wait for 1.2?
>
>Well, you could pinch 1.0.1 but we're giving it away free so that's
>hardly stealing. ha ha ha
>
>Seriously though, the answer to your question is: wait for 1.2
Ok
Bye,
A.H.
Re: alfanum.cls, etc. (was: Re: PR-1.0.3... and latexconf)
On Thu, 11 Feb 1999, Arnd Hanses wrote:
> Hi,
>
> now that LyX 1.0.0 bug reporting is calming down a little, I would like
> to discuss the possibility of releasing alfnum.cls, etc.
>
> The files I've mailed to the list a month ago, attached as alfanum.zip
> or similar. If somebody has missed them, just ask me.
>
> Also I'm looking forward to receive some bug reports, suggestions,
> fixes, etc. in order to improve this.
One bug I fixed in LyX (after 1.0.0) that your alfanum.layout triggered
was reading (and ignoring of) carriage-returns ('\r') which would crash
LyX when reading the alignment possibilities from the layout file.
So you may want to ensure that the next release doesn't have any '\r's in
it at all just to be sure you don't trigger any crashes in LyX versions
<=1.0.0 (I did send an email about this previously but I think its one of
the ones that disappeared into the ether).
> What I cannot do is changing the
> LyX code (I'm not a programmer) so that it looks less ugly in LyX (Xdvi
> is perfect). I definitely would like to see the numbers in LyX, too,
> before finally releasing it. Otherwise it would not be WYSIWYM, I
> think, i.e. not really working together with LyX.
Don't worry about the numbering. It's WYSIWYM to have all arabic
numbering and WYSIWYG to have correct numbering.
IEEEtran also has non-arabic numbering schemes and for the 1.0 series its
also stuck with arabic-only numbering onscreen in LyX. This will change
in 1.1.x so don't worry about it. Just add a small note to that effect in
the documentation for alfanum.
> On Tue, 02 Feb 1999 11:57:28 +0200, Martin Vermeer wrote:
>
> >looks fascinating. ...
> >What fascinates me is your definition of greek letters for section titles,
> >and the massive number of section levels. I might want to pinch that :-)
>
> Martin,
>
> what does 'pinch' mean here? Did it work?
pinch is slang for steal, ie. if you pinch something then you stole it.
(other interesting slang terms for steal: snavel, nick, lift)
> Is it possible to 'pinch' it together with 1.0.1 (could be another new
> feature), or should we wait for 1.2?
Well, you could pinch 1.0.1 but we're giving it away free so that's
hardly stealing. ha ha ha
Seriously though, the answer to your question is: wait for 1.2
> Greetings,
>
> A.H.
Cheers,
Allan. (ARRae)
alfanum.cls, etc. (was: Re: PR-1.0.3... and latexconf)
Hi, now that LyX 1.0.0 bug reporting is calming down a little, I would like to discuss the possibility of releasing alfnum.cls, etc. The files I've mailed to the list a month ago, attached as alfanum.zip or similar. If somebody has missed them, just ask me. Also I'm looking forward to receive some bug reports, suggestions, fixes, etc. in order to improve this. What I cannot do is changing the LyX code (I'm not a programmer) so that it looks less ugly in LyX (Xdvi is perfect). I definitely would like to see the numbers in LyX, too, before finally releasing it. Otherwise it would not be WYSIWYM, I think, i.e. not really working together with LyX. On Tue, 02 Feb 1999 11:57:28 +0200, Martin Vermeer wrote: >looks fascinating. ... >What fascinates me is your definition of greek letters for section titles, >and the massive number of section levels. I might want to pinch that :-) Martin, what does 'pinch' mean here? Did it work? Is it possible to 'pinch' it together with 1.0.1 (could be another new feature), or should we wait for 1.2? Greetings, A.H.
latexconf
http://visar.csustan.edu/bazaar/bazaar_list.html In addition to the hebrew word processor, there's something that looks like (a piece of) what Martin was requesting for LaTeX. And apparently someone's working on it. -Amir
Re: PR-1.0.3... and latexconf
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> I wouldn't be so sure... typically what you find are packages Martin> that change things to a different, but equally rigid scheme. Martin> This is really a thing that has disappointed me a little in Martin> LaTeX. Of course it has its value for fixing a style for Martin> journal articles e.g. which is consistent; but it is not good Martin> that there is no flexibility at all. Well, for sections, the ultimate flexible tool exists, it is \@startsection. Packages which redfine sections are just wrappers around that. >> * classes: paper.cls, koma-script * packages: fncychap.sty, >> secsty.sty, section.sty, caption.sty, caption2.sty Martin> section.sty and fncycap.sty look somewhat interesting. But, Martin> limited in the ways that I outlined above. (and this is not Martin> something that you should *need* add-on packages for!) Well, design this ultimate flexible documentclass then. Remember that the article document class was intended a a basic class. It is a bit unfortunate that it became the standard. >> There are probably many others. Martin> Can't say that I've stumbled over them :-) Well, I did this list by browsing the LaTeX Catalogue 5 minute. I'm sure there are a couple of others. >> Note that it is not a good idea to have local copies of standard >> document classes with the same name. In fact, Martin> ^^ Martin> True. So lyxarticle.cls, lyxbook.cls, ... with same Martin> functionality but "handles" added. Hmm? I'd rather have a name without 'lyx' in it and to make sure that it remains a pure LaTeX project. But be warned that this is a lot of work to get right. JMarc
Re: PR-1.0.3... and latexconf
> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes: Arnd> This is what I'm trying to do in a limited way with my Arnd> alfanum.cls: just adding things I'd like to see in LyX. (I'm Arnd> using LyX/2, the OS/2 port of Miyata san; three cheers for his Arnd> work, combined with EmTeX and XDVI/2 it's blazingly fast). Yes, his work is certianly impressive. Arnd> Larry, did it work for you? Just one typo: Use 'Labeltype' Arnd> instead of 'LabelType' in 'alfanumber.layout'! These should be case independent. JMarc
Re: PR-1.0.3... and latexconf
On Tue, 02 Feb 1999 11:57:28 +0200, Martin Vermeer wrote: >> I would suggest also to have a look into jura.cls and alphanumeric.sty of CTAN. > >I did; looks fascinating. However this is not quite what I had in mind. >Didn't find alfanum.cls, though. Yes I see, your project is the fast and easy LyX user configuration of LaTeX docs. My approach is more simplistic: Write layouts (like 'alfanumber.cls'; alfanum.cls is obsolete, destroyed that long ago, sorry) which make the preformatted rigid LaTeX classes operational in LyX. I think if need be, it would be easier to write parallel extended classes or meta-classes for use in LyX which include those of CTAN and allow the most necessary modifications with simple menu options or shortcuts. >What fascinates me is your definition of greek letters for section titles, >and the massive number of section levels. I might want to pinch that :-) Yes, fascinates me that You are fascinated like other LaTeXperts are; I recently looked into old Hegel's 'Phänomenologie des Geistes': Now I can assure You all: They are TeXnical standard in academic typesetting at least since 1807. Somebody apparently has forgotten something...
Re: PR-1.0.3... and latexconf
On Mon, 01 Feb 1999 20:16:45 +0200, Martin Vermeer wrote: >True. So lyxarticle.cls, lyxbook.cls, ... with same functionality >but "handles" added. Hmm? > This is what I'm trying to do in a limited way with my alfanum.cls: just adding things I'd like to see in LyX. (I'm using LyX/2, the OS/2 port of Miyata san; three cheers for his work, combined with EmTeX and XDVI/2 it's blazingly fast). I would suggest also to have a look into jura.cls and alphanumeric.sty of CTAN. Three days ago I mailed my aproach to get preliminary alphanumeric sectioning support (was: 'alphanumeric section numbering'). [EMAIL PROTECTED] would have a glimpse into it: Larry, did it work for you? Just one typo: Use 'Labeltype' instead of 'LabelType' in 'alfanumber.layout'! P.S.: Koma-etc. is great to produce the more traditional typeset. Regards, AH
Re: PR-1.0.3... and latexconf
*Amir Karger writes: | Also, what makes it emacs-style? vim can do it too, e.g. Created when reading the vc.el files. Lgb
Re: PR-1.0.3... and latexconf
> "Rich" == Rich Fields at 407 356 5842 <[EMAIL PROTECTED]> writes: >> That's why I think that, if we decide to build the ultimate >> configurable class, the first thing to do is ask for help on >> comp.text.tex. Such a project should be a pure LaTeX project at >> first. When it works, then we will be able to add support in LyX >> for that. Rich> I agree. :) (Whew. I almost volunteered for something again.) I have to add that the `we' I used was a generic `we'. I did not intend to include me in (though I can give my usual range of useless and rude comments) :) JMarc
Re: PR-1.0.3... and latexconf
Jean-Marc writes > > "Rich" == Rich Fields at 407 356 5842 <[EMAIL PROTECTED]> writes: > Rich> This is where I fall short in using latex2e. I was a heavy > Rich> latex2.09 user starting in the mid/late-80s and had to create > Rich> significant hacks to areas like you are discussing and > Rich> more. Unfortunately, I then became so comfortable at being able > Rich> to hack latex code that the modern era of all these new > Rich> pre-packaged, documented, structured style files passed me by, > Rich> and now I'm trying to re-learn how to use latex with these new > Rich> packages (most of which are great). > > That's why I think that, if we decide to build the ultimate > configurable class, the first thing to do is ask for help on > comp.text.tex. Such a project should be a pure LaTeX project at > first. When it works, then we will be able to add support in LyX for > that. [snip] I agree. :) (Whew. I almost volunteered for something again.) Rich
Re: PR-1.0.3... and latexconf
> "Rich" == Rich Fields at 407 356 5842 <[EMAIL PROTECTED]> writes: Rich> This is where I fall short in using latex2e. I was a heavy Rich> latex2.09 user starting in the mid/late-80s and had to create Rich> significant hacks to areas like you are discussing and Rich> more. Unfortunately, I then became so comfortable at being able Rich> to hack latex code that the modern era of all these new Rich> pre-packaged, documented, structured style files passed me by, Rich> and now I'm trying to re-learn how to use latex with these new Rich> packages (most of which are great). That's why I think that, if we decide to build the ultimate configurable class, the first thing to do is ask for help on comp.text.tex. Such a project should be a pure LaTeX project at first. When it works, then we will be able to add support in LyX for that. This approach has several advantages: - we'll work with people who know what they are doing - I suppose that many things already exist, and we don't want to re-do them - if such a package ends up in standard LaTeX places (CTAN, teTeX) then we'll be able to share documents with LaTeX people without sending a bunch of style files. JMarc
Re: PR-1.0.3... and latexconf
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > > > Martin> While leafing through book.cls (renamed to fgibook.cls, > > Martin> fgibook.layout to follow) I noticed that there is so much > > Martin> stuff hardwired that could be put into a variable using > > Martin> \newcommand. Some stuff is user redifinable (like certain > > Martin> names, or numbering achemes etc.), but most is just hardwired > > Martin> or cumbersome to redefine by the user. > > > > I think there exist classes/packages which allow to redefine many > > things. A first job will probably be to find out what these > > classes/packages are and whether they are suited for what we want. > > I wouldn't be so sure... typically what you find are packages that > change things to a different, but equally rigid scheme. > > This is really a thing that has disappointed me a little in LaTeX. > Of course it has its value for fixing a style for journal articles > e.g. which is consistent; but it is not good that there is no flexibility > at all. > > The way it should be is, that if you want something fundamentally > different (e.g. a letter instead of a journal article) then you > get a different class. If you want *some aspect* of your doc to be > fundamentally different, you get a .sty package for that. Example: > hanging captions with caption.sty. > > But *it should be possible* (for a package like LyX) to change small, > trivial things in simple, obvious ways without programming; it may not > be so that we have replaced mark-up coding successfully with an > on-screen, visual feedback paradigm, but still are editing the > document definitions in the oldfashioned primitive (=programming) way! This is where I fall short in using latex2e. I was a heavy latex2.09 user starting in the mid/late-80s and had to create significant hacks to areas like you are discussing and more. Unfortunately, I then became so comfortable at being able to hack latex code that the modern era of all these new pre-packaged, documented, structured style files passed me by, and now I'm trying to re-learn how to use latex with these new packages (most of which are great). I bring this up because my latex history means I have no fear of latex internals (if this is good or bad I'm not sure). If there are small latex hacks needed, and we can't get a true modern latexpert on the list, I might be able to help some. (But it would be best if there was a true latexpert that could at least consult to see if any hacks created interfere with something else.) Rich
Re: PR-1.0.3... and latexconf
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> While leafing through book.cls (renamed to fgibook.cls, > Martin> fgibook.layout to follow) I noticed that there is so much > Martin> stuff hardwired that could be put into a variable using > Martin> \newcommand. Some stuff is user redifinable (like certain > Martin> names, or numbering achemes etc.), but most is just hardwired > Martin> or cumbersome to redefine by the user. > > I think there exist classes/packages which allow to redefine many > things. A first job will probably be to find out what these > classes/packages are and whether they are suited for what we want. I wouldn't be so sure... typically what you find are packages that change things to a different, but equally rigid scheme. This is really a thing that has disappointed me a little in LaTeX. Of course it has its value for fixing a style for journal articles e.g. which is consistent; but it is not good that there is no flexibility at all. The way it should be is, that if you want something fundamentally different (e.g. a letter instead of a journal article) then you get a different class. If you want *some aspect* of your doc to be fundamentally different, you get a .sty package for that. Example: hanging captions with caption.sty. But *it should be possible* (for a package like LyX) to change small, trivial things in simple, obvious ways without programming; it may not be so that we have replaced mark-up coding successfully with an on-screen, visual feedback paradigm, but still are editing the document definitions in the oldfashioned primitive (=programming) way! > * classes: paper.cls, koma-script > * packages: fncychap.sty, secsty.sty, section.sty, caption.sty, > caption2.sty section.sty and fncycap.sty look somewhat interesting. But, limited in the ways that I outlined above. (and this is not something that you should *need* add-on packages for!) > There are probably many others. Can't say that I've stumbled over them :-) > Martin> And modifying a class file of course requires root > Martin> privileges. No problem for us Linuxers, but... > > Does not need any root priviledge: just have the local copy somewhere > earlier in the search path. OK, good to know. Thanks! > Note that it is not a good idea to have > local copies of standard document classes with the same name. In fact, ^^ True. So lyxarticle.cls, lyxbook.cls, ... with same functionality but "handles" added. Hmm? > LaTeX licence prohibits from distributing such classes. > > JMarc > Martin
Re: PR-1.0.3... and latexconf
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> While leafing through book.cls (renamed to fgibook.cls, Martin> fgibook.layout to follow) I noticed that there is so much Martin> stuff hardwired that could be put into a variable using Martin> \newcommand. Some stuff is user redifinable (like certain Martin> names, or numbering achemes etc.), but most is just hardwired Martin> or cumbersome to redefine by the user. I think there exist classes/packages which allow to redefine many things. A first job will probably be to find out what these classes/packages are and whether they are suited for what we want. * classes: paper.cls, koma-script * packages: fncychap.sty, secsty.sty, section.sty, caption.sty, caption2.sty There are probably many others. Martin> And modifying a class file of course requires root Martin> privileges. No problem for us Linuxers, but... Does not need any root priviledge: just have the local copy somewhere earlier in the search path. Note that it is not a good idea to have local copies of standard document classes with the same name. In fact, LaTeX licence prohibits from distributing such classes. JMarc
Re: latexconf
Amir Karger wrote: > > The latexconf idea is great. Although it seems like LaTeX already has tons > of parameters, there are clearly a bunch of lengths and texts which are > hard-coded. However, it sounds to me like a major project, which only > overlaps with LyX at the later (easier) parts. And we seem to have only a > couple latex gurus in the core devvie group. Maybe some lurkers would > volunteer to help? TeTeX-9 can use the ../tex dir in LyX and supports ls-R there, so in the not too distant future, the problem of having to have root privs will go away. The book class should be called Text-Book anyway. It is ridiculous for a Story-Book. In general, latex satisfies academic needs---no small problem--- but if support for general literature, plays, odd poetry, songs etc. is there, it is not very accessible. Making it easier to write/modify class files and submit them to LyX could significantly extend the user group. > > One example you might want to look at for ideas is natbib, which makes the > \cite command much more expressive (using \citep et al). I wonder if there's > other stuff going on among the comp.text.tex folks, or on CTAN, involving > making LaTeX more configurable? We wouldn't want to repeat work that's been > done, after all. Obviously we want to take full advantage of prior work, but LyX users are not necessarily the same sort of beasts as LaTeX gurus. I think the most important thing is to stick to JMarc's principles that LyX produces great output that does not offend the eye of a professional typesetter. -- Garst
latexconf
The latexconf idea is great. Although it seems like LaTeX already has tons of parameters, there are clearly a bunch of lengths and texts which are hard-coded. However, it sounds to me like a major project, which only overlaps with LyX at the later (easier) parts. And we seem to have only a couple latex gurus in the core devvie group. Maybe some lurkers would volunteer to help? One example you might want to look at for ideas is natbib, which makes the \cite command much more expressive (using \citep et al). I wonder if there's other stuff going on among the comp.text.tex folks, or on CTAN, involving making LaTeX more configurable? We wouldn't want to repeat work that's been done, after all. -Amir
Re: PR-1.0.3... and latexconf
Ready to Rock & Roll. :-) Best regards -- Larry S. Marso [EMAIL PROTECTED] On Sun, Jan 31, 1999 at 05:50:06PM +0200, Martin Vermeer wrote: > Here is the 1.0.3 version
Re: PR-1.0.3... and latexconf
[looks great, we all love it, blah blah blah] I have to agree with Larry on the "emacs-style" thing. Why not just say "version control for collaborative authoring". Anyone who knows what version control is doesn't need to be told it's emacs-style, while anyone who doesn't know has at least a *chance* of getting an idea of what it's for if you say the shorter version above. Their eyes will glaze over if they see emacs-style, IMO. Also, what makes it emacs-style? vim can do it too, e.g. -Amir
PR-1.0.3... and latexconf
Here is the 1.0.3 version with two point corrections only.
I have also been thinking about the "latexconf" idea, as this weekend I had
to design a class file for out Institute's Reports series. (The proposed
design was so awful that I couldn't keep my mouth shut. No good deed goes
unpunished.)
While leafing through book.cls (renamed to fgibook.cls, fgibook.layout
to follow) I noticed that there is so much stuff hardwired that could be
put into a variable using \newcommand. Some stuff is user redifinable
(like certain names, or numbering achemes etc.), but most is just hardwired
or cumbersome to redefine by the user.
And modifying a class file of course requires root privileges. No problem for
us Linuxers, but...
E.g. the Chapter header in Book consists of "Chapter X" in big, on a line,
followed by "Title of this chapter" in even bigger on the next line.
The space above, between and under these is hardwired. The text "Chapter"
before the number can be modified, but not the symbol after the number
(which symbol? right!). And it's all flush left.
Or take captions. I used captions.sty to get hanging captions as required.
Only snag, it writes "Figure 1: " whereas required is
"Figure 1. ". (I successfully changed the numbering scheme from
Chapter.fig to fig using numberwithin). So how to change the colon to a
period?
So I introduced the \newcommand \captionseparator, default equal to ":" but
user-settable to "." Commands are nothing but substitution rules.
The fact that any significant change to the style of a LaTeX document requires
not only root privileges but a knowledge of a "little language", is OK when
preparing documents for a journal having class files on its home page; but what
about all those people out there that just want to write, not program, but
still have to conform with some format requirements?
So, here is my idea for an approach. It will require changing the LaTeX classes
and styles, which is tricky as they are not ours to change, and forking is a
bad idea too. The changes to be made would be: go through each file and change
all fixed things that a user would possibly want to change, to a command name
(= substitution string). This can be done without changing the functionality
of the class (well, it may slow down a little, but that's insignificant
with today's computers), but providing large numbers of "handles" to
configuration things to be redefined using \renewcommand.
E.g. take
\newcommand\section{\@startsection {section}{1}{\z@}%
{-3.5ex \@plus -1ex \@minus -.2ex}%
{2.3ex \@plus.2ex}%
{\normalfont\Large\bfseries}}
in article.cls. Change it to
\newcommand{\sectionstyle}{\normalfont\Large\bfseries}
\newcommand{\sectionbeforeskip}{-3.5ex \@plus -1ex \@minus -.2ex}
\newcommand{\sectionafterskip}{2.3ex \@plus.2ex}
\newcommand\section{\@startsection {section}{1}{\z@}%
{\sectionbeforeskip}%
{\sectionafterskip}%
{\sectionstyle}}
...and in your preamble you can change \sectionstyle etc. by hand!
One this is done, you can make a file .latexconf into your user directory,
containing all these possible \renewcommands, mostly commented out, but
some modified by you. The preamble can \input this file. Or separate files
.article.conf, .book.conf etc.
For us who are not frightened by having to edit config files, this would be
quite enough; but from here on it would be comparatively easy to build a GUI
editing tool with friendly menus etc. either inside LyX or standalone and
called from the LyX menu system, like reLyX.
An approach like this would *really* have the potential to make LyX a realistic
alternative for the "programming-challenged" set out there.
What do you think?
Martin
-
Public release of LyX version 1.0.0
===
LyX is an advanced open source document processor running on many Unix
platforms. It is called a "document processor", because unlike standard
word processors, LyX encourages an approach to writing based on the
structure of your documents, not their appearance. LyX lets you
concentrate on writing, leaving details of visual layout to the software.
LyX automates formatting according to predefined rule sets, yielding
consistency throughout even the most complex documents. LyX produces high
quality, professional output -- using LaTeX, an open source, industrial
strength typesetting engine, in the background.
With LyX, short notes or letters are a snap. LyX really shines, though,
when composing complex documents like technical documentation, doctoral
theses and conference proceedings.
LyX has undergone a quantum leap in functional
Re: another thought about "latexconf"
>>>>> "Larry" == Larry S Marso <[EMAIL PROTECTED]> writes:
Larry> Another superior feature for the proposed "latexconf" facility
Larry> would be the ability to create defined terms. I'm imagining a
Larry> *LyX* entry field, in which you could enter either text
Larry> formatted using LyX's ordinary set of Layout tools, or even
Larry> enter ERT, with LyX outputing interpreted LaTeX into a
Larry> \def\VAR1{ } in the preamble. You'd then need a new
Larry> Insert->Defined Term function, to insert \VAR1, etc., where
Larry> desired. The Insert->Defined Term command could bring up a
Larry> menu showing variable names and a "comment" the user added to
Larry> describe it when created..
What you are describing is an extension of mathed marcos facility to
normal text. I agree that this would be a great thing.
JMarc
another thought about "latexconf"
Another superior feature for the proposed "latexconf" facility would be the
ability to create defined terms. I'm imagining a *LyX* entry field, in
which you could enter either text formatted using LyX's ordinary set of
Layout tools, or even enter ERT, with LyX outputing interpreted LaTeX into
a \def\VAR1{ } in the preamble. You'd then need a new Insert->Defined
Term function, to insert \VAR1, etc., where desired. The Insert->Defined
Term command could bring up a menu showing variable names and a "comment"
the user added to describe it when created..
I just *have* to point out that such a facility --- which would basically
stick ERT in the LaTeX preamble --- could even function as a (much easier
to code?) solution to our ERT widget problem. Think about it.
Best regards
--
Larry S. Marso
[EMAIL PROTECTED]
Re: latexconf? (Was Re: Three pre-versions of PR doc)
On Sat, 23 Jan 1999, Liisa Vermeer wrote: Snip --->8 > Yeah, the are good at copying. I believe that the whole original idea of > paragraph styles, style sheets, etc. was pinched straight from LaTeX. > (well, > where did Lamport get it from originally? Wasn't there a software called > 'Scribe'?) Good ideas get copied. Which is one of the reasons why free software works. :-) > Snap 8<--- > Martin (from his wife's Wintendo) > My wife uses Linux :-) , at least at home :-)
Re: latexconf? (Was Re: Three pre-versions of PR doc)
On Sat, Jan 23, 1999 at 08:28:22AM -0500, Larry S. Marso wrote: > On Sat, Jan 23, 1999 at 02:59:12PM -0800, Liisa Vermeer wrote: > > > > It is the idea for a little program that can be called "latexconf", > > whose > > only function it would be to interactively compose a file redefining > > many of the environments used e.g. in "article". Ahhh. I missed "interactively" the first time I read this. Very good idea. It should certainly be combined with a facility for saving multiple environmental definitions, after you've gone through the trouble of specifying parameters. Best regards -- Larry S. Marso [EMAIL PROTECTED]
Re: latexconf? (Was Re: Three pre-versions of PR doc)
On Sat, Jan 23, 1999 at 02:59:12PM -0800, Liisa Vermeer wrote: > > I have actually an idea worth thinking about ... > It is the idea for a little program that can be called "latexconf", > whose > only function it would be to interactively compose a file redefining > many of the environments used e.g. in "article". It would just write out > \renewcommand lines with options for every environment to be redefined, > and the file is to be included at the start of your document (or through > a LyX hook). > > A similar thing (redefining styles) is part of MS Word. (Nobody I know > uses it :-) I don't quite understand. We have class/layout files, which permit choice of a "documentclass" that will redefine environments, etc., behind the scenes. Alternatively, you can input specific changes in a LaTeX preamble, without changing documentclass. Right now, using "set environment as default" you can save one specific LaTeX preamble, so that it will appear in each new document. Are you talking about a facility that let's you save several different LaTeX preambles, and choose which one you want to use in a new document? Best regards -- Larry S. Marso [EMAIL PROTECTED]
latexconf? (Was Re: Three pre-versions of PR doc)
Asger K. Alstrup Nielsen wrote: > > > - Which one do you prefer? (why?) > > I prefer the last one, because it explains the WYSIWYM principle the best. That makes two out of two. And I'm the third (but didn't want to bias you all). Question is now: Does anybody have a problem with 3, or consider 2 clearly better? > There are a few typos: "ar" -> "are". > Latex -> LaTeX. Hmmm, as soon as I'm back into Linux. > What You See Is What you MEAN -> What You See Is What You Mean. Intentionally. Emphasized. Oops, y -> Y. > As some of you know, I use Microsoft Windows daily, and in particular > Word. The other day I noticed that Microsoft Word actually is I commiserate. > introducing more and more of the logical editing. [long story cut short] > But it's worth keeping an > eye on, because it seems that others begin to notice the advantage of > taking advantage of the screen. Yeah, the are good at copying. I believe that the whole original idea of paragraph styles, style sheets, etc. was pinched straight from LaTeX. (well, where did Lamport get it from originally? Wasn't there a software called 'Scribe'?) Good ideas get copied. > Word is an excellent application to use, if you have tried LyX first. > Then you know how to use Word in the right way. (This might be something > worth touting at some point: Using LyX educates you to use your other > word processor better ;-) Definitely true. I refer to my earlier note about how my colleagues write section headers using finger paint. Recently I found (and had to type it into our web page) an "instructions to authors" page containing instructions about how to format contributions using Word. "The other headers in BIG letters, numbered, flush left. Headers and paragraphs to be separated by one blank line without indent." Beautiful, ain't it? ;-} I have actually an idea worth thinking about but for which I will have no time to do anything about in the near future, although it fascinates me. It is the idea for a little program that can be called "latexconf", whose only function it would be to interactively compose a file redefining many of the environments used e.g. in "article". It would just write out \renewcommand lines with options for every environment to be redefined, and the file is to be included at the start of your document (or through a LyX hook). A similar thing (redefining styles) is part of MS Word. (Nobody I know uses it :-) This would make it easier for people that cannot write their own class files (the vast majority) to tailor existing class files (mostly, article and book) to their needs without a Ph.D. Such a utility could be written in tcl/tk or perl/tk (as we already have perl-reLyX). Everything GUI, of course. This would fit in nicely with Larry Marso's idea for a "LyX Usability Project", but would produce more result with less effort than just going out on a wild goosechase for dozens of class/layout files -- which people would all have to try out anyway before knowing what they are good for, and still wouldn't precisely be what their publisher insists upon. Opinions? Martin (from his wife's Wintendo)
