Re: Refernces
Use Refworks to export your references as Bibtex. A .bib file should be generated. Then follow the intructions in LyX's User's Guide (Help->User's Guide, section 6.5.1) to insert your references in the document. Cheers, Nicolás Hesham Kamel wrote: Hello, I am writing my thesis now, and just knew about LATEX. I downloaded LyX, and started to work with, however I have a concern. In MS Word, I am using a citation manager, Refworks to insert citations, and at the end it produces a bibliography numbered list, while in the main document itself, it generates references to the list according to the selected style. e.g. a full frontal impact can extend for more than half a day even with current computational capabilities [1]. and 1. REFERENCES [1] Natori, S., and Yu, Q., 2007, "2007-01-0882 an Application of CAP (Computer-Aided Principle) to Structural Design for Vehicle Crash Safety," SAE SP, (2072) pp. 73-80. so, can I get the same using LyX? Do I need any additional software? Thank you,
Re: Progress on the MS Word to LyX conversion (xml)
On Tuesday 22 July 2008 19:24, Pavel Sanda wrote: > > Pavel Sanda wrote: > > Moreover, if you're editing by hand, you can use > > something that recognizes XML. > > of course it will work, but it will take x-times more time. > quite difference to write sed one-liner or start doing some > xslt templating. > > pavel Yeah, I think this was the point I was trying to get across. With the current format, you can do a lot with Vim. Or you can run through a series of small filters that do just one thing. XML's a different animal. Without a parser, it's almost impossible to handle. With a parser, you're forced to work only within the language of that parser, and you're forced to make a monolithic solution that can't take advantage of Unix pipes and small executables that do one thing and do it well. You also forgo the ability to have a series of intermediate files, each serving as a test point to make sure things are still going well. Also, an XML parser, especially a DOM one, makes READING XML very easy, but it does nothing for WRITING. Pavel -- you and I and others like us need to start identifying parsing tools to at least partially compensate for the loss of our Unix based pipes with small filter executables. Theoretically, if one could read the XML into a DOM tree, tweak it in memory, and then write it back out, that would be at least somewhat doable, though nothing like the Awk and Perl techniques I'm used to. And once again, we need COMPLETE documentation on the XML dialect, and Like I said I'm willing to help with that documentation. SteveT Steve Litt Recession Relief Package http://www.recession-relief.US
Re: How to make a clone of the Enumerate environment?
On Wednesday 23 July 2008 00:54, Dirk Markert wrote: > 2008/7/22 Steve Litt <[EMAIL PROTECTED]>: > > Günter (and everyone else), > > > > Your response contains one of the most useful LyX idioms I've ever seen, > > limiting my biggest objection to LyX. It will lead to vastly improved > > productivity for me. > > > > Can anyone guess which part of Günter's email is so useful? I'll reveal > > it in > > another email, coming up shortly. > > CopyStyle? > > Dirk Yes! It looks like my subsequent message didn't go through, but it was CopyStyle. Let me look into what happened to my second post. STeveT Steve Litt Recession Relief Package http://www.recession-relief.US
Re: Inconsistent indentation behaviour after LyX-Code and Program Listing Inset
On 20.07.08, Paul A. Rubin wrote: > Jürgen Spitzmüller wrote: >> Anyway, I don't think you'll find a working example. As listings fails >> with multibyte glyphs, it will also fail when multibyte glyphs are used >> in ERT, no? > Not according to the documentation. You can define an "escape to LaTeX" > character, and anything bracketed by that character is handed off to > LaTeX verbatim. According to the docs, that allows you to put multibyte > characters in a comment (though apparently _only_ in a comment). > Anyway, I can't find a way to test this here, since I don't have any CJK > fonts installed and wouldn't know how to use them if I did. You can insert a comment with some accented latin characters (like ä or é) and set the encoding to utf8. > If this is an issue, we'll find out when someone barks about it. Until > then, I'm not sure it's worth worrying about. True again. BTW: While German does not depend on a multibyte encoding, the German umlauts are multibyte characters in UTF-8. Günter
Re: how can i put a citation in an ert endnote?
On 21.07.08, Glen Whitehead wrote: > Dear all, > I'm using LyX 1.5.4 and ERT to insert endnotes. However, I do not seem > able to add citations to an ERT. Please send your suggestions :) Find out the latex code for your citation and insert it as ERT: 1. Open the Source View (View>View Source) 2. Insert your citation (as a dummy) *outside of* the ERT box 3. Copy the generated LaTeX command from the Source View to the ERT box. 4. Delete the dummy citation. This technique should work for all special insets. Günter
Re: Documentation of LyX functions (aka LFUNs)
On 23.07.08, Pavel Sanda wrote: > Dear LyXers, > I'm proud to announce that the LFUNs documentation project has been finished. Good news. Many thanks to you. > * HTML documentation was produced via doxygen. The file could be found here: > http://www.lyx.org/~sanda/doxygen/html/namespacelyx.html > or you can go directly to the right section: > > http://www.lyx.org/~sanda/doxygen/html/namespacelyx.html#5ae63e8160e98b54ad28f142ed40c202 This html page is HUGE. It would be helpfull (especially for people on slower net connections and not so powerfull machines) to have the lfuns section in a separate html document. (Of course I can use the pdf as well, but the active links in the html are an added bonus.) > I would appreciate all bug reports (i.e. some lfun does not work in the way > its documented), typo in documentation etc. What is the preferred destination for bug reports, [EMAIL PROTECTED] ? Thanks again, Günter
Re: Life changing LyX idiom gives me new productivity
On 22.07.08, Steve Litt wrote: > Hi all, > In a different thread, Gunter Milde penned these words: > > You need to clone both, LyX layout:: > > > > Style Questions > > CopyStyle Enumeration > > > That is THE most powerful LyX idiom I've ever seen. > When I have time I'll check whether I can actually change appearances > in LyX like this: > Style MyNewStyle > CopyStyle Standard > LeftMarginMMM > RightMargin MMM > Font > SizeLarger > EndFont > End > If that's possible, then within LyX I can see at a glance that my new > style is custom, and that I later have to develop the LaTeX to complete > it. I'd use a different colour (or sans-serif fonts), but this is a matter of taste. Maybe a label (like Label myStyle ) would be an idea as well, but might be too distracting in the text. BTW, you can leave out > CopyStyle Standard if you want to clone Standard, as Standard is what a new style copies by default. > So Gunter -- thanks SO much for that idiom. It makes LyX a much more > useful tool. You are welcome. However, I just found this idiom in the sources (and the Customization guide -- always read the docs). My and your thanks should go to the one who actually implemented the CopyStyle keyword! One more useful idiom: Style MyTemplate Label myStyle LabelFont SeriesMedium Shape Italic Size Small Color blue EndFont # ... more definitions End Style MyEnv CopyStyle MyTemplate # changes End # more private styles ... # Remove auxiliary style NoStyle MyTemplate See my dinbrief.layout version on the lyx wiki as an example. Günter
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 00:19:09 Pavel Sanda wrote: > by 'outside' i mean tweakings which i regularly do and watching users list > power users do that too _and_ are happy about the current simplicity of > format. > > tweaks like assembling of the whole file for various datasets, global > changes of things (cf notes-mutate lfun i introduced lately), conversions > and so on. This works well for simple things but breaks badly when you try something a bit more complex. > while you are right that xml could be better technology for internal > lyx parsing (and i can understand your viewpoint as lyx2lyx fan:) > this was not my mail about. > > > It is funny to see all this nostalgia around something that is/was a > > nightmare. > > it has nothing to do with nostalgia, but speed of hacking around. Not when the resulting file crashes lyx, something that should not ever happen but that it does now. First make it correct and then make it fast. XML will not change the current status. grep
Re: Progress on the MS Word to LyX conversion (xml)
> On Wednesday 23 July 2008 00:19:09 Pavel Sanda wrote: > > while you are right that xml could be better technology for internal > > lyx parsing (and i can understand your viewpoint as lyx2lyx fan:) > > this was not my mail about. > > > > > It is funny to see all this nostalgia around something that is/was a > > > nightmare. > > > > it has nothing to do with nostalgia, but speed of hacking around. > > Not when the resulting file crashes lyx, something that should not ever > happen > but that it does now. i've done incorrect file, it's my fault if lyx crashes. i take my responsibility, no problem. trial method is the fastest if you want something quickly. > First make it correct and then make it fast. i have exactly oposite view as far as the tweaking i was talking about is concerned; i just need quickly output of something, may be i will throw it away after few days. or take Steve's example - if he takes your 'First make it correct and then make it fast' it would take some two weaks to invent some beast to be correct in your sense. but then the whole point is lost, since after this time he could do it manually. i guess we can't agree on this, since i'm not talking about lyx internals, while your job is to make lyx format conversions on lyx level... but this is users list, not the the devel one, so i feel free to speak this way :) pavel
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 12:19:16 Pavel Sanda wrote: > i've done incorrect file, it's my fault if lyx crashes. i take my > responsibility, no problem. > trial method is the fastest if you want something quickly. If LyX crashes that is a bug. LyX should not ever crash, it can refused to load a file because it is invalid, or to truncate it but it should not ever crash. In the whole picture our parser is one of our weak links so we should do something about it. Replace it in this case. > > First make it correct and then make it fast. > > i have exactly oposite view as far as the tweaking i was talking about > is concerned; i just need quickly output of something, may be i will throw > it away after few days. > > or take Steve's example - if he takes your 'First make it correct and then > make it fast' it would take some two weaks to invent some beast to be > correct in your sense. but then the whole point is lost, since after this > time he could do it manually. > > i guess we can't agree on this, since i'm not talking about lyx internals, > while your job is to make lyx format conversions on lyx level... but this > is users list, not the the devel one, so i feel free to speak this way :) Yes, I know but I can pretend otherwise. ;-) > pavel -- José Abílio
Re: replace text
I don't know about you, but I find having lots of ERTs in my document
distracting and a bit annoying!
My solution is similar but instead I use the math mode - that way I see the
actual symbol I typed...
eg, include the following line in your Preamble
\newcommand{\hho}{\text{H}_2\text{O}}
Then inside your document simply type Command-m (or Ctrl-m on a PC?) which
starts the equation editor
enter \hho as your equation and hit space a couple of times.
You should now have a nice compiled H20 to look at in your LyX document.
So that I can see for example the Angstrom symbol I type Command-m \text
space \AA Command-end (ie \text{\AA}) so that I actuall can see it rather
than an annoying ERT.
Chris.
Re: Progress on the MS Word to LyX conversion (xml)
Guys, Have you even looked at TinyXML? I have a project once where we use XML as a message passing protocol and we were using XSLT as C++ code generator for classes handling XML and converting them to data structures handling all data we need. This freed us from portability problems (Litte Endian, Big Endian) which is not case here. For the application like LyX binary structure may be better to handle - certainly much work to do. We in our project hadn't found any known DOM useful for our purpose. Cheers! M. 2008/7/23 José Matos <[EMAIL PROTECTED]>: > On Wednesday 23 July 2008 12:19:16 Pavel Sanda wrote: > > i've done incorrect file, it's my fault if lyx crashes. i take my > > responsibility, no problem. > > trial method is the fastest if you want something quickly. > > If LyX crashes that is a bug. LyX should not ever crash, it can refused to > load a file because it is invalid, or to truncate it but it should not ever > crash. > > In the whole picture our parser is one of our weak links so we should do > something about it. Replace it in this case. > > > > First make it correct and then make it fast. > > > > i have exactly oposite view as far as the tweaking i was talking about > > is concerned; i just need quickly output of something, may be i will > throw > > it away after few days. > > > > or take Steve's example - if he takes your 'First make it correct and > then > > make it fast' it would take some two weaks to invent some beast to be > > correct in your sense. but then the whole point is lost, since after this > > time he could do it manually. > > > > i guess we can't agree on this, since i'm not talking about lyx > internals, > > while your job is to make lyx format conversions on lyx level... but this > > is users list, not the the devel one, so i feel free to speak this way :) > > Yes, I know but I can pretend otherwise. ;-) > > > pavel > > -- > José Abílio > -- Manveru jabber: [EMAIL PROTECTED] gg: 1624001 http://www.manveru.pl
Re: Progress on the MS Word to LyX conversion (xml)
On Tuesday 22 July 2008 18:21, José Matos wrote: > Clearly you did not had to deal with the lyx file format like I did. :-) > If your idea of a parser is a set of regexp's that is so 80's. ;-) [clip] > It is funny to see all this nostalgia around something that is/was a > nightmare. If the syntax was so clear you would not have the problem of > crashing lyx with a bad formed file (a file modified by scripts). When the discussion reverts to "your thingamabob is from another decade/century so it must not be good by today's standards", you know that thingamabob is pretty darn good, or else there would have been a more powerful argument against it. First of all, I understand *exactly* why an XML native format is an improvement for the LyX application. I'm limiting my point to the concept that something old has to be something bad. Modern things are usually improvements, but often are not improvements in quality or usefulness. They can be improvements to profit margin (e.g. most MS Windows "improvements"), or marketing improvements (all the silly little expensive features thrown into basic family cars today), or improvements in restricting use (DRM), or improvements in price (crummy bicycles from Walmart). Sometimes older stuff has more quality or usefulness. In 1969 and the early 1970's, Ken Thompson and the gang made Unix with the philosophy of little executables that do one thing and do it right. Stdin, stdout and pipes were the glue language with which these little executables could be cascaded to produce a substantial result. This enabled logical-thinking non-developers, and also developers, to produce those substantial results in an hour, with perhaps the greatest encapsulation that's ever been achieved in the computer world. Each little executable has one input and one output, each being a measurable test point. For batch processes this "programming" technique is every bit as productive as it was 39 years ago. There may be things wrong with awking, seding and perling data into submission, but the age of these tools is not one of them. SteveT Steve Litt Recession Relief Package http://www.recession-relief.US
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 07:00, José Matos wrote: > XML will not change the current status. > > grep
Re: Progress on the MS Word to LyX conversion (xml)
On Tuesday 22 July 2008 19:24, Pavel Sanda wrote: > > Pavel Sanda wrote: > > Moreover, if you're editing by hand, you can use > > something that recognizes XML. > > of course it will work, but it will take x-times more time. > quite difference to write sed one-liner or start doing some > xslt templating. > > pavel Hi Pavel, Perhaps our best hope of continuing tweakability of native LyX is to create 1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can continue to be done in the 1.5.x format. I'm presuming that the LyX developers will create the 1.5.x to XML converter so users can upgrade their old docs, and hopefully they would keep that converter updated for each new LyX version, so that you and I wouldn't need to worry about coding the 1.5.x to XML. The only thing you and I would have to do is the XML to 1.5.x converter. I'm pretty darned good with C, and if necessary I can do C++ (but with a C accent). If we pick an XML parser with full schema/dtd capability, that doesn't have many dependencies, then if you know how to write 1.5.x, I can feed you whatever data is needed to write the 1.5.x. There's another possibility that I think might be better. Using Ruby with REXML, I could convert the XML to YAML (http://en.wikipedia.org/wiki/Yaml) if you could help me just a little bit with the return trip (YAML to XML). I think this would be EVEN BETTER than 1.5.x, because YAML was made for exactly what you and I want to do -- parsing with awk/sed/perl/grep/cut. It would also remove our responsibility to support 1.5.x syntax in the 22nd century. Using YAML for tweaking, I think there may come a time when you and I would say "remember when we had to parse that nasty 1.5.x?" I can begin this project as soon as the developers give me an XML def and an XML file. That way, once they actually specify what they're going to do, we'll have the technology for the XML->YAML->XML round trip, and only the details will require coding. What do you think? StevET Steve Litt Recession Relief Package http://www.recession-relief.US
Re: Progress on the MS Word to LyX conversion (xml)
Steve Litt wrote: Perhaps our best hope of continuing tweakability of native LyX is to create 1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can continue to be done in the 1.5.x format. I'm presuming that the LyX developers will create the 1.5.x to XML converter so users can upgrade their old docs, and hopefully they would keep that converter updated for each new LyX version, so that you and I wouldn't need to worry about coding the 1.5.x to XML. Yes, switching to XML doesn't mean abandoning lyx2lyx. The difference is that we will be able to use simpler XSL templates for the conversion. The advantage being that the XSL templates will be available to all, not being specificy to python or lyx2lyx. By the way, the switch to XML is not going to happen with 1.6 but with 1.7, that is at least one year from now ;-) The only thing you and I would have to do is the XML to 1.5.x converter. This will be provided by lyx2lyx too. 1.7-XML will export to all 1.x formats with x <= 6. I'm pretty darned good with C, and if necessary I can do C++ (but with a C accent). If we pick an XML parser with full schema/dtd capability, that doesn't have many dependencies, then if you know how to write 1.5.x, I can feed you whatever data is needed to write the 1.5.x. As I said above, this 1.7 to 1.6 will be supported via a simple XSL stylesheet. It's really the other direction 1.6 to 1.7 that will be difficult to implement. But hey, all help is welcome, the development of 1.7 is going to begin in a couple of months so if you want to have a say in the new XML format, come along on the devel list ;-) Abdel.
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 15:33:16 Steve Litt wrote: > The trouble is, XML tags can be anywhere -- spacing and linefeeds are > immaterial. That means you can no longer parse based on position, such as: > > /^begin_layout/ > > because technically the whole XML file could be in a single line. Or a > single tag could be split between lines. Since we control the format I am (almost) sure that we will choose a reader friendly output. There is no reason to do otherwise. In terms of size a blank or a newline are equivalent, so... :-) That is why it will be business as usual. :-) Not much will change in this regard. -- José Abílio
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 15:20:59 Steve Litt wrote: > When the discussion reverts to "your thingamabob is from another > decade/century so it must not be good by today's standards", you know that > thingamabob is pretty darn good, or else there would have been a more > powerful argument against it. Pavel is a developer just as I am. In this thread we been teasing each other over this issue. In such cases this is an acceptable argument (IMO). ;-) > First of all, I understand *exactly* why an XML native format is an > improvement for the LyX application. I'm limiting my point to the concept > that something old has to be something bad. That is fair. :-) > Modern things are usually improvements, but often are not improvements in > quality or usefulness. They can be improvements to profit margin (e.g. most > MS Windows "improvements"), or marketing improvements (all the silly little > expensive features thrown into basic family cars today), or improvements in > restricting use (DRM), or improvements in price (crummy bicycles from > Walmart). Sometimes older stuff has more quality or usefulness. All that is true but in this case the lyx file format and indirectly the lyx parser have not been changed in a long time until 2002 not because they were perfect but because most developers were afraid to touch and break it. The format had been evolving over time and it was a mess with places where whitespaces were significant and others were they were for no good reason. > In 1969 and the early 1970's, Ken Thompson and the gang made Unix with the > philosophy of little executables that do one thing and do it right. Stdin, > stdout and pipes were the glue language with which these little executables > could be cascaded to produce a substantial result. This enabled > logical-thinking non-developers, and also developers, to produce those > substantial results in an hour, with perhaps the greatest encapsulation > that's ever been achieved in the computer world. Each little executable has > one input and one output, each being a measurable test point. For batch > processes this "programming" technique is every bit as productive as it was > 39 years ago. lyx2lyx that lyx uses to convert between the different file formats works using this principle, it acts as a filter receiving from stdin and writing the transformation in stdout. Yet until now there is not a good way to have an external program (script) other than lyx to check the validity of a lyx file. For me, at least, this is a strong shortcoming of our file format. > There may be things wrong with awking, seding and perling data into > submission, but the age of these tools is not one of them. If you add there the coreutils, like tail, cut, paste, merge and so on we can do things that spreadsheet programs can only dream of like processing Gigs of data with thousands of lines and columns. :-) > SteveT -- José Abílio
Re: Inconsistent indentation behaviour after LyX-Code and Program Listing Inset
G. Milde wrote: On 20.07.08, Paul A. Rubin wrote: Jürgen Spitzmüller wrote: Anyway, I don't think you'll find a working example. As listings fails with multibyte glyphs, it will also fail when multibyte glyphs are used in ERT, no? Not according to the documentation. You can define an "escape to LaTeX" character, and anything bracketed by that character is handed off to LaTeX verbatim. According to the docs, that allows you to put multibyte characters in a comment (though apparently _only_ in a comment). Anyway, I can't find a way to test this here, since I don't have any CJK fonts installed and wouldn't know how to use them if I did. You can insert a comment with some accented latin characters (like ä or é) and set the encoding to utf8. If this is an issue, we'll find out when someone barks about it. Until then, I'm not sure it's worth worrying about. True again. BTW: While German does not depend on a multibyte encoding, the German umlauts are multibyte characters in UTF-8. Günter Thanks for the tip, Günter. I'm attaching a small proof-of-concept example that shows three things: 1. The version of the listing done in ERT comes out correctly, including Günter's two example multibyte characters. 2. The version done with a listing inset (which has the ä removed for reasons I'll mention in a minute) comes out but with the second comment garbled. I assume this is because forcing latin1 encoding results in the two bytes of é being interpreted as separate characters. 3. If you put the ä back in the document and try to compile it, not only are the two bytes interpreted as separate characters, but one of them apparently is not available in T1, so LaTeX throws an error message. That last part means that we may not be entirely successful in protecting the user from himself (unless Jürgen's patch fixes that). All that said, it's not an issue for me, and I don't recall any users complaining that their comments turned into Klingon, so it's not a priority issue. Cheers, Paul
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 15:58:56 Steve Litt wrote: > Hi Pavel, > > Perhaps our best hope of continuing tweakability of native LyX is to create > 1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can > continue to be done in the 1.5.x format. I will advise against such practice. I hope to explain why in the paragraphs below. > I'm presuming that the LyX developers will create the 1.5.x to XML > converter so users can upgrade their old docs, and hopefully they would > keep that converter updated for each new LyX version, so that you and I > wouldn't need to worry about coding the 1.5.x to XML. Note that the convertion to xml will only happen after 1.6. I know that your argument remains unchanged with this shift and just correct this before continuing. With this said lyx2lyx will be able to convert from pre-xml to xml and vice- versa. Our previous experience suggest however that while the forward translation is complete the backwards translation results sometimes in the truncation or lots of ERT added to preserve the same structure. For several reasons a transformation from X to X+1 and back again is not guaranteed to give the same document bit by bit. Note also that this is not an easy task in any way. The next question is why do we need to manipulate lyx files with awk and friends? Is not there something that can should be done by lyx? I have generated lyx files with scripts that have been used in my PhD thesis (almost 40 pages were generated like this) so I can recognize advantages in manipulating lyx files with scripts, but in that case there are better tools than awk and sed. That is also the reason why lyx2lyx is nowadays mostly a python library (LyX.py) and the script lyx2lyx is just a wrapper around the library. > The only thing you and I would have to do is the XML to 1.5.x converter. > I'm pretty darned good with C, and if necessary I can do C++ (but with a C > accent). If we pick an XML parser with full schema/dtd capability, that > doesn't have many dependencies, then if you know how to write 1.5.x, I can > feed you whatever data is needed to write the 1.5.x. > > There's another possibility that I think might be better. Using Ruby with > REXML, I could convert the XML to YAML (http://en.wikipedia.org/wiki/Yaml) > if you could help me just a little bit with the return trip (YAML to XML). > I think this would be EVEN BETTER than 1.5.x, because YAML was made for > exactly what you and I want to do -- parsing with awk/sed/perl/grep/cut. It > would also remove our responsibility to support 1.5.x syntax in the 22nd > century. > > Using YAML for tweaking, I think there may come a time when you and I would > say "remember when we had to parse that nasty 1.5.x?" > > I can begin this project as soon as the developers give me an XML def and > an XML file. That way, once they actually specify what they're going to do, > we'll have the technology for the XML->YAML->XML round trip, and only the > details will require coding. > > What do you think? > > StevET You are welcome both to tell us your requirements around the future xml file format and to help us so that in the end we all have a better lyx. Really, all help is welcome. > Steve Litt > Recession Relief Package > http://www.recession-relief.US -- José Abílio
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 14:49:12 Manveru wrote: > Guys, > > Have you even looked at TinyXML? Thanks for the link. :-) -- José Abílio
Re: Documentation of LyX functions (aka LFUNs)
On Wed, 23 Jul 2008, Pavel Sanda wrote: I'm proud to announce that the LFUNs documentation project has been finished. Great work! If you are interested in mastering LyX this documentation could be useful for your needs. Should we put this in a page on the wiki site? It could just be a copy of your announcement that's put in a page in the development group, e.g. http://wiki.lyx.org/Devel/LFUN Then we can link to that page from the page http://wiki.lyx.org/LyX/LyxFunctions and eventually integrate the results. What do you think? /Christian -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: Inconsistent indentation behaviour after LyX-Code and Program Listing Inset
Paul A. Rubin wrote: I'm attaching a small proof-of-concept example that shows three things: Let me rephrase that: once I wake up, I'll be attaching ... listingsExample.lyx Description: application/lyx
Re: Why 2 bibliographies?
NEVERMIND. There was no problem, it was just 2nd page. I'm an idiot... Sorry for your time spent reading this. :blush: H wrote: > > Hello, I use LyX 1.5.5 with Inlinebib and Koma-script book with in-line > full citations style (working almost perfect). > The problem is the final bibliography (which would resume and sort all > references already cited in the text): > > the unwanted result is 2 bibliographies: > 1st one with correct Koma chapter character style > 2nd one is with another (roman?) character style > > Every reference is listed in just one of the two, with almost no criteria, > perhaps some of the most complex references are in 2nd bibliography... And > perhaps there are some more references in the 1st one. No references left > outside the 2 bibliographies. > I'm puzzled... > > -- View this message in context: http://n2.nabble.com/Why-2-bibliographies--tp534947p578782.html Sent from the LyX - Users mailing list archive at Nabble.com.
Re: Inconsistent indentation behaviour after LyX-Code and Program Listing Inset
Paul A. Rubin wrote: > > I'm attaching a small proof-of-concept example that shows three things: > > Let me rephrase that: once I wake up, I'll be attaching ... The example compiles fine in 1.6svn. It's probably too tricky to backport the changes to 1.5. Jürgen
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 11:21, José Matos wrote: > > There may be things wrong with awking, seding and perling data into > > submission, but the age of these tools is not one of them. > > If you add there the coreutils, like tail, cut, paste, merge and so on we > can do things that spreadsheet programs can only dream of like processing > Gigs of data with thousands of lines and columns. :-) :-) :-) :-) Check this out: http://www.troubleshooters.cxm/lpm/200801/200801.htm http://www.troubleshooters.cxm/lpm/200802/200802.htm But seriously -- it's obvious that for the LyX application itself, XML is by far the best way to go, and I would never suggest rewriting LyX in awk :-). My interest is in quick writes/tweaks of LyX native format files in order to do things that LyX isn't equipped to do, like my VimOutliner to LyX script. STeveT Steve Litt Recession Relief Package http://www.recession-relief.US
Re: Progress on the MS Word to LyX conversion (xml)
On Wednesday 23 July 2008 11:05, José Matos wrote: > On Wednesday 23 July 2008 15:33:16 Steve Litt wrote: > > The trouble is, XML tags can be anywhere -- spacing and linefeeds are > > immaterial. That means you can no longer parse based on position, such > > as: > > > > /^begin_layout/ > > > > because technically the whole XML file could be in a single line. Or a > > single tag could be split between lines. > > Since we control the format I am (almost) sure that we will choose a reader > friendly output. There is no reason to do otherwise. In terms of size a > blank or a newline are equivalent, so... :-) > > That is why it will be business as usual. :-) > Not much will change in this regard. Thanks José, As a sed/awk/perl/ruby parser, I appreciate that very much. The more I think about it, the more I think I should make the XML->YAML and YAML->XML converters. That way, if future generations of LyX project programmers forget why it's important to space their XML "just so", it won't matter. Also, I have a feeling that YAML will be much easier to parse than either 1.5.x or XML. The way I envision it, these two converters will be simple standalone commands implemented as filters (convert stdin to stdout), very few dependencies. They will comply with the Unix Philosophy (little apps that do one thing and do it well). Trivial to install. They will be simple enough to be maintained by one person. They will be encapsulated. They won't need to know about LyX other than its XML format, and LyX won't need to know about them. They can be included in the LyX distribution, or not. At first I'll do them in Ruby because Ruby has all that stuff built in and easy to do. Later, depending on performance and the percent of people who have Ruby installed, I can convert them to C. There's a C implementation of the same YAML parser/emitter that Ruby uses -- Syck. I'm pretty sure there are also C or C++ implementations of XML Parsers, although I don't know how well they do things like DTD/schema. Thanks SteveT Steve Litt Recession Relief Package http://www.recession-relief.US
two sided woes and ragged2e use
Greetings List,
Finishing up the layout on my masters thesis written with Bean ---> LyX
a terrific combo for OS X. Thanks to everybody involved in improving
and developing this wonderful program.
running LyX 1.5.5 on PPC Mac OS X 10.5.4
Problem:
When two sided document is chosen (koma-script Book Class, or Book
Class) alternating Right Left pages fails when \pagenumbering{roman}
goes to \pagenumbering{arabic}. Problem does not occur when using all
{arabic}. I tried \frontmatter and \mainmatter first but that caused
bizarre numbering with the child documents. I've attached a main file
and a child document that recreates the problem.
Question:
I am using the ragged2e package for my whole document but would like
the chapter Abstracts justified. How do I add "justified" to a single
page? (such as the abstract page of the attached child document).
Thank you for your time,
Zan
#LyX 1.5.5 created this file. For more info see http://www.lyx.org/
\lyxformat 276
\begin_document
\begin_header
\textclass scrbook
\begin_preamble
\usepackage{ragged2e}
\raggedright
\setlength{\parindent}{20pt}
\renewcommand{\theequation}{Eq. \arabic{equation}}
\usepackage{graphicx}
\usepackage[font=small,labelfont=small,labelfont=bf,labelsep=period]{caption}
\newcommand{\sups}[1]{\raisebox{1ex}{\small #1}}
\newcommand{\subs}[1]{\raisebox{-.8ex}{\small #1}}
\usepackage{indentfirst}
\end_preamble
\language english
\inputencoding auto
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\paperfontsize 12
\spacing double
\papersize letterpaper
\use_geometry true
\use_amsmath 0
\use_esint 0
\cite_engine natbib_authoryear
\use_bibtopic false
\paperorientation portrait
\leftmargin 1.75in
\topmargin 1in
\rightmargin 1in
\bottommargin 1in
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle plain
\tracking_changes false
\output_changes false
\author ""
\author ""
\end_header
\begin_body
\begin_layout Chapter
\paragraph_spacing single
Annual Water and Solute Export from the Yukon River and its Tributaries
\end_layout
\begin_layout Standard
\newpage
\end_layout
\begin_layout Standard
\begin_inset VSpace vfill*
\end_inset
\end_layout
\begin_layout Standard
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
addcontentsline{toc}{section}{Abstract}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\paragraph_spacing single
\noindent
\align center
\series bold
ABSTRACT
\end_layout
\begin_layout Standard
\paragraph_spacing single
Annual export of eleven major and trace solutes are determined for the Yukon
River based on summing 42 tributary contributions.
First we show that annual discharge of the Yukon River at three mainstem
locations can be computed by summing calculated annual discharges from
42 tributaries.
Annual discharge for the ungaged tributaries is calculated from basin area
and average annual precipitation over that area using a previously published
regional regression equation.
Based on tributary inputs we estimate an average annual discharge for the
Yukon River of 211\InsetSpace ~
\family roman
\series medium
\shape up
\size normal
\emph off
\bar no
\noun off
\color none
\begin_inset Formula $km^{3}\: yr^{-1}$
\end_inset
\family default
\series default
\shape default
\size default
\emph default
\bar default
\noun default
\color inherit
.
This value is within 2% of the average measured annual discharge at the
USGS gaging station at Pilot Station, AK for water years 2001 through 2005.
Next, annual loads for 11 solutes are determined by combining annual discharge
with point measurements of solute concentrations in tributary river water.
Based on the sum of tributary water we find that the Yukon River discharges
approximately 33 million metric tons of dissolved solids each year at Pilot
Station.
Discharged solutes are dominated by cations calcium and magnesium (5.66x10
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
sups{12}
\end_layout
\end_inset
and 1.42x10
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
sups{12}
\end_layout
\end_inset
\begin_inset Formula $g\: yr^{-1}$
\end_inset
) and anions bicarbonate and sulfate (17.2x10
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
sups{12}
\end_layout
\end_inset
and 5.42x10
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
sups{12}
\end_layout
\end_inset
\begin_inset Formula $g\: yr^{-1}$
\end_inset
.
These loads compare well with loads calculated using the USGS computer
program LOADEST based on daily discharge and 34 instantaneous solute concentrat
ion measurements at three locations along the Yukon River.
Annual solute loads determined by summing tributary contributions show
an
hypertarget in LyX
I read all of my PDFs on the computer now, rather than print them out. Hence
I always like it when people use internal referencing within their PDFs.
Other than a basic reference to a figure number or external URL it is
sometime handy to link a word in your document to a particular section so
that it can be clicked on to navigate to that page.
For example, sometimes I mention a name. At the end of my PDF I list who all
the people are I have mentioned. I can create an internal reference with
some ERT to the persons description
\hypertarget{lyx:H.-Kiel}{H.\,Kiel} - sets the label
\hyperlink{lyx:H.-Kiel}{H.\,Kiel} - links back to the label
Is there a way in LyX to do this without the ERTs? I can't even figure it
out in LyX 1.6beta4
In the insert cross-refference tool it has a field to specify a name, but
you can't enter anything in the field. Does anyone know what this is for?
Should I be using prettyref - what ever it is?
Cheers,
Chris.
Re: Progress on the MS Word to LyX conversion (xml)
> Perhaps our best hope of continuing tweakability of native LyX is to create > 1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can > continue to be done in the 1.5.x format. as have written others 1.6 is still ok. for lyx files assembly you can still make what you want in 1.6 format and lyx2lyx will convert for you to 1.7 etc. next possibility is to stick with 1.6 as long as possible :) > The only thing you and I would have to do is the XML to 1.5.x converter. I'm this will be part of the the fileformat transition in lyx itself. moreover xml is not my religion, so i will try to keep myself as far as possible from any xml related coding :D pavel
We could really use search-for-environment and search-for-charstyle
Hi all, One feature I think would be really helpful in LyX would be search-for-environment and search-for-character-style. That way I wouldn't need to go into Vim every time I wanted to locate a specific character style. Thanks SteeveT Steve Litt Recession Relief Package http://www.recession-relief.US
Re: Progress on the MS Word to LyX conversion (xml)
> The next question is why do we need to manipulate lyx files with awk and > friends? Is not there something that can should be done by lyx? search and replace is one of the weak lyx parts and even if we get Tommaso one day to put his stuff in there are so many place where its of no help. just look on the things like notes-mutate or graphics settings synchronization other nonimplemented things come to my mind. > I have generated lyx files with scripts that have been used in my PhD thesis > (almost 40 pages were generated like this) so I can recognize advantages in > manipulating lyx files with scripts, but in that case there are better tools > than awk and sed. this depends on what you master. i'm used on the bunch of small unix utilities so i gave that sed example. if you know python you will do in python. my point was not propose the best tools but to groan and moan about xml :) pavel
Re: Documentation of LyX functions (aka LFUNs)
>> If you are interested in mastering LyX this documentation could be useful >> for your needs. > > Should we put this in a page on the wiki site? It could just be a copy of > your announcement that's put in a page in the development group, e.g. > > http://wiki.lyx.org/Devel/LFUN > > Then we can link to that page from the page > http://wiki.lyx.org/LyX/LyxFunctions > and eventually integrate the results. i have already put the section here, so from my point of view its finished. when 1.6 is out we can replace the whole page by the current version. or we can put the .lyx file into LyX help menu. dont know if others think its good idea. by the way - Uwe, i have hidden wish - would it be possible for you to produce ONE BIG LYX documentation for all the manuals together (plus lfuns.lyx) - each file could be one part for example... ? i search often for some keyword and always get frustrated about ten different documments to look in. we can even put this as main documentation link from our official site. > What do you think? feel free to do whatsover you want :) pavel
Re: Documentation of LyX functions (aka LFUNs)
> This html page is HUGE. It would be helpfull (especially for people on > slower net connections and not so powerfull machines) to have the lfuns > section in a separate html document. (Of course I can use the pdf as well, > but the active links in the html are an added bonus.) you can play with it of course :) just run 'doxygen' command in your svn tree (sourcedoc directory). you get the page for any tweaking before you put it in wiki. :) > > I would appreciate all bug reports (i.e. some lfun does not work in the way > > its documented), typo in documentation etc. > > What is the preferred destination for bug reports, [EMAIL PROTECTED] ? lyx-devel is the best. pavel
Re: Progress on the MS Word to LyX conversion (xml)
On Wed, Jul 23, 2008 at 10:33:16AM -0400, Steve Litt wrote: > On Wednesday 23 July 2008 07:00, José Matos wrote: > > > XML will not change the current status. > > > > grep
Re: Documentation of LyX functions (aka LFUNs)
Pavel Sanda schrieb: i have already put the section here, so from my point of view its finished. when 1.6 is out we can replace the whole page by the current version. Yes, please do so. or we can put the .lyx file into LyX help menu. dont know if others think its good idea. I don't know if this is a good idea as this are informations for specialists and developers. by the way - Uwe, i have hidden wish - would it be possible for you to produce ONE BIG LYX documentation for all the manuals together (plus lfuns.lyx) - each file could be one part for example... ? This can be done, but not yet. I'm working to get the docs ready for LyX 1.6 and processing a 1000+ pages document is time consuming. I could provide such a file maybe when LyX 1.6.0 is out, but you can of course try to do it yourself. regards Uwe
Re: Documentation of LyX functions (aka LFUNs)
> Yes, please do so. > >> or we can put the .lyx file into LyX help menu. dont know if others think >> its good idea. > > I don't know if this is a good idea as this are informations for > specialists and developers. you are probably right, help menu is overpopulated even now. > I could > provide such a file maybe when LyX 1.6.0 is out, this was exactly my wish >but you can of course try > to do it yourself. i'm afraid of the preambles i have seen :) of course i will compile some beast privately if you wont release anything official :) pavel
Re: Inconsistent indentation behaviour after LyX-Code and Program Listing Inset
Jürgen Spitzmüller wrote: Paul A. Rubin wrote: I'm attaching a small proof-of-concept example that shows three things: Let me rephrase that: once I wake up, I'll be attaching ... The example compiles fine in 1.6svn. It's probably too tricky to backport the changes to 1.5. No reason to waste irreplaceable developer brain cells on backporting something nobody is asking for. :-) If it becomes an issue for someone, they can either use ERT or upgrade to 1.6 once it goes gold. /Paul
Re: support arabic in lyx
hatim ali schrieb: Dear lyx team The po-updates mailing list is only to send there .po file updates. To get help from the community. please write to the lyx-users or the lyx-devel mailing list. i can't use arabic in lyx, and i don't know why i can't. and when i import any "arabic tex" file i get unknown chracter. please see the attachment file (image + arabic.tex). The problem is that our TeX file import program can still not use any other character encoding than "latin1". Fixing this was one of our goals for LyX 1.6.0 but due to lack of manpower we haven't reached this goal :-( So the only thing you can do is to open the .tex file with an editor and copy/paste text parts to your LyX file. So we have to admit that LyX is currently only really usable in non-European languages when you create your own LyX documents without importing TeX files. Attached is a LyX file to be used with LyX1.6beta4 created from your TeX file. regards Uwe first stepar.lyx Description: application/lyx
Problem with Lyx 1.5.5 (Windows, Miktex) when converting to PS
Hello, I have a 5 years old Lyx-file, a bit complicated, 50 pages. Converting with Lyx 1.5.5 (Windows XP Prof., Miktex, AFPL GS 8.54) to PS results in the error message below. And Lyx is rather slow. I have Lyx 1.4.5 on the same machine and it converts the Lyx-file (and is faster). If have another Lyx 1.5.3 in Ubuntu (in a VMWare virtual machine running on the same PC), which also converts (fast). Two questions: 1. Any idea, how to solve the problem below? What does it mean? 2. Can I work in Lyx 1.5.5 and continue working on the document in Lyx 1.4.5 or Lyx 1.5.3? Has the file format remained the same? Thanks! Michael GSview 4.8 2006-02-25 Unknown in Comments section at line 8: %%DocumentFonts: Palatino-Roman Palatino-Italic Palatino-Bold PazoMath Unknown in Comments section at line 9: %%+ CMSY10 PazoMath-Italic CMR10 CMMI10 CMEX10 Unknown in Prolog section at line 333: %%CreationDate: 1992 Jul 23 21:22:48 Unknown in Prolog section at line 400: %%CreationDate: 1996 Jul 23 07:53:57 Unknown in Prolog section at line 470: %%CreationDate: 1991 Aug 15 07:20:57 Unknown in Prolog section at line 529: %%CreationDate: Fri May 17 11:17:28 2002 Unknown in Prolog section at line 530: %%VMusage: 12 15 DSC Information At line 535: /Notice (Copyright (c) Diego Puga, 2000, 2002. Distributed under the GNU General Public License (http://www.gnu.org/copyleft/gpl.txt). As a special exception, permission is granted to include this font program in a PostScript or PDF file that consists of Lines in DSC documents must be shorter than 255 characters. Unknown in Prolog section at line 631: %%CreationDate: 1992 Feb 19 19:54:52 Unknown in Setup section at line 5100: %%BeginPaperSize: a4 Unknown in Setup section at line 5102: %%EndPaperSize AFPL Ghostscript 8.54 (2006-05-17) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. While reading gs_dbt_e.ps: Error: /undefined in --get-- Operand stack: (gs_fntem.ps) 1 FontEmulationProcs encodingnames --nostringval-- --nostringval-- StandardEncoding --nostringval-- ISOLatin1Encoding --nostringval-- SymbolEncoding --nostringval-- DingbatsEncoding --nostringval-- SymbolEncoding --nostringval-- DingbatsEncoding --nostringval-- ISOLatin1Encoding --nostringval-- StandardEncoding dings --dict:4/16(G)-- dings Execution stack: %interp_exit --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- 17 5 %oparray_pop --nostringval-- --nostringval-- --dict:17/21(ro)(G)-- --dict:1/1(G)-- --nostringval-- 1 %dict_continue --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:933/1123(G)-- --dict:0/20(G)-- --dict:64/200(L)-- --dict:933/1123(G)-- --dict:10/10(G)-- Current allocation mode is global Current file position is 6521 gsapi_init_with_args returns -100 -- Michael Logies, Zahnarzt, Große Straße 28, D-49134 Wallenhorst, http://www.logies.de/ (u. a. _die_ Mailingliste für die Dentalbranche), PGP-/OpenPGP-Schlüssel (RSA/IDEA) kann angefordert werden.
Re: Progress on the MS Word to LyX conversion (xml)
Steve Litt wrote: On Wednesday 23 July 2008 07:00, José Matos wrote: XML will not change the current status. grep
Re: Progress on the MS Word to LyX conversion (xml)
Steve Litt wrote: Perhaps our best hope of continuing tweakability of native LyX is to create 1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can continue to be done in the 1.5.x format. As always, LyX will have such converters, so old formats can be imported/exported. rh
Re: Problem with Lyx 1.5.5 (Windows, Miktex) when converting to PS
On Wednesday 23 July 2008 20:56, Michael Logies wrote: > Hello, > 2. Can I work in Lyx 1.5.5 and continue working on the document in Lyx > 1.4.5 or Lyx 1.5.3? Has the file format remained the same? No. 1.5.x is a different format from 1.4.x, and once you go 1.5.x, you can't go back. I use 1.5.3 and haven't noticed anything all that slow on my 300 page books. Where is it slow for you, and how slow? SteveT Steve Litt Recession Relief Package http://www.recession-relief.US
Re: Progress on the MS Word to LyX conversion (xml)
José Matos wrote: That is also the reason why lyx2lyx is nowadays mostly a python library (LyX.py) and the script lyx2lyx is just a wrapper around the library. And let me add that anyone who wants to process LyX files on a regular basis using external scripts would be well served to learn the basics of this library. The interface is really very simple once you get the hang of it. rh
Re: Progress on the MS Word to LyX conversion (xml)
Steve Litt wrote: At first I'll do them in Ruby because Ruby has all that stuff built in and easy to do. Later, depending on performance and the percent of people who have Ruby installed, I can convert them to C. There's a C implementation of the same YAML parser/emitter that Ruby uses -- Syck. I'm pretty sure there are also C or C++ implementations of XML Parsers, although I don't know how well they do things like DTD/schema. At present, it's LyX policy that included things should be in Python, since we require it anyway. rh
The "\DeclareMathOperator"command in my lyx doesn't work,please help!
Hello
I'm new to Lyx. I wanted to add a "\arccot" self-defined function in my
document, and I followed the help's instruction to add
"\DeclareMathOperator{\arccot}{arccot}" in "Document->settings...->LaTeX
Preamble", but after I did it, nothing happened. When I typed "\arccot", it
still does not act like "\sin" or "\arctan". It does't turn to upright font.
With my research getting deeper, I found that the hlep document "Math.lyx"
in my LYX, also suffered from the similar failure. In this document, the
examples which should've demonstrated the usage of "\DeclareMathOperator"
doesn't work too, including "\\DeclareMathOperator*{\Lozenge}{\blacklozenge}"
and "\DeclareMathOperator{\sgn}{sgn}".
My Operating System is Windows xp sp2, and the lyx version is 1.5.5.
Thank you for your help, and sorry for my poor English expression.
LittleNew
Re: Problem with Lyx 1.5.5 (Windows, Miktex) when converting to PS
At 24.07.2008 03:17 Steve Litt wrote: > No. 1.5.x is a different format from 1.4.x, and once you go 1.5.x, > you can't go back. Steve, thanks for clarification. > I use 1.5.3 and haven't noticed anything all that slow on my 300 page > books. Where is it slow for you, and how slow? The 58 pages take 1:35 (95 seconds) with Lyx 1.5.5 (for PS) till gsview comes up with the error message (PIV, 3 GHz, 3 GB RAM, Win XP Prof.) Lyx 1.4.5 takes 1:25 and succeeds. Both need 6 rounds of Latex. Regards Michael -- Michael Logies, Zahnarzt, Große Straße 28, D-49134 Wallenhorst, http://www.logies.de/ (u. a. _die_ Mailingliste für die Dentalbranche), PGP-/OpenPGP-Schlüssel (RSA/IDEA) kann angefordert werden.
Re: The "\DeclareMathOperator"command in my lyx doesn't work,please help!
LittleNew wrote:
Hello
I'm new to Lyx. I wanted to add a "\arccot" self-defined function in my
document, and I followed the help's instruction to add
"\DeclareMathOperator{\arccot}{arccot}" in "Document->settings...->LaTeX
Preamble", but after I did it, nothing happened. When I typed "\arccot", it
still does not act like "\sin" or "\arctan". It does't turn to upright font.
With my research getting deeper, I found that the hlep document "Math.lyx"
in my LYX, also suffered from the similar failure. In this document, the
examples which should've demonstrated the usage of "\DeclareMathOperator"
doesn't work too, including "\\DeclareMathOperator*{\Lozenge}{\blacklozenge}"
and "\DeclareMathOperator{\sgn}{sgn}".
Is the problem that it doesn't look right in LyX itself or in the LaTeX
output? I don't think it will look any different in LyX. But it should
look right in the output.
rh
Re: Documentation of LyX functions (aka LFUNs)
Pavel Sanda wrote: > or we can put the .lyx file into LyX help menu. dont know if others think > its good idea. I think it's a good idea, this is useful information. Maybe as an appendix to Customization? Jürgen
Re: two sided woes and ragged2e use
Zan wrote:
> Problem:
> When two sided document is chosen (koma-script Book Class, or Book
> Class) alternating Right Left pages fails when \pagenumbering{roman}
> goes to \pagenumbering{arabic}. Problem does not occur when using all
> {arabic}. I tried \frontmatter and \mainmatter first but that caused
> bizarre numbering with the child documents. I've attached a main file
> and a child document that recreates the problem.
try \cleardoublepage instead of \pagebreak (Insert->Formatting->Clear Double
Page).
> Question:
> I am using the ragged2e package for my whole document but would like
> the chapter Abstracts justified. How do I add "justified" to a single
> page? (such as the abstract page of the attached child document).
embrace the Abstract by
\justifying
...
\RaggedRight
Jürgen
