Re: Postscript preview
On Jul 29, 2006, at 9:09 PM, Stephen Harris wrote: LB wrote: When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? Yes I did. I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some "must have" new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo I didn't have any bright ideas. But since it seems you are close to giving up, I thought I would toss out some longshots. " PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly " (from 7/28/2006 12:03 pm, PATH report) SH: Maybe that is a typo the "ly" looks wrong. As Jose mentions, upgrading Ghostscript might help, because version 7.07 had a bug with paths with spaces. A very longshot is that the local LyX Python is buggy with utf8 support but those files don't cure it. Do you have the full Python installed? If so put it at the front of Path_prefix statement in LyX and it will supersede the local partial version of Python. Vaguely, the locale might connect to the set commands. I said it was a longshot. The set command used to say set lang=en_US if one used English. I couldn't find info on what LC does... Anyway replacing GS is a good idea, and if you already have the full Python, it is easy to *_prepend_* C:\Python243 to the LyX Path_prefix and have a fully functioning Python, since the extent of the local Python, mostly successful, may have other gaps. I've had a problem with set environmental variables once before. Another departed version of *tex had left its value behind and conflicted with the new version which wanted to set the same variable to a new place. (Cygwin and TexLive2005). Well, that was just rambling. Hi, one more idea: if this is really a PATH problem and things worked normally under lyx 1.4.1, then I would do the following simple steps (unless you already tried this and I didn't see it in the earlier messages): (a) Revert to LyX 1.4.1 and open the Preferences dialog to find out EXACTLY what your PATH setting is in that program. (b) Copy that string. (c) Re-install LyX 1.4.2 and open the Prefs dialog there to see its PATH settings. I would strongly suspect that this is somehow different from 1.4.1. (d) Enter the previously copied PATH from 1.4.1 into the PATH box in 1.4.2. (e) Restart LyX 1.4.2 (just to be safe), and see if the preview works now. Hope that helps, Jens
Re: Postscript preview
LB wrote: When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? Yes I did. I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some "must have" new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo I didn't have any bright ideas. But since it seems you are close to giving up, I thought I would toss out some longshots. " PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly " (from 7/28/2006 12:03 pm, PATH report) SH: Maybe that is a typo the "ly" looks wrong. As Jose mentions, upgrading Ghostscript might help, because version 7.07 had a bug with paths with spaces. A very longshot is that the local LyX Python is buggy with utf8 support but those files don't cure it. Do you have the full Python installed? If so put it at the front of Path_prefix statement in LyX and it will supersede the local partial version of Python. Vaguely, the locale might connect to the set commands. I said it was a longshot. The set command used to say set lang=en_US if one used English. I couldn't find info on what LC does... Anyway replacing GS is a good idea, and if you already have the full Python, it is easy to *_prepend_* C:\Python243 to the LyX Path_prefix and have a fully functioning Python, since the extent of the local Python, mostly successful, may have other gaps. I've had a problem with set environmental variables once before. Another departed version of *tex had left its value behind and conflicted with the new version which wanted to set the same variable to a new place. (Cygwin and TexLive2005). Well, that was just rambling. -- An ambient confluence of mapped coherence ~ Stephen
Re: Postscript preview
> When you added the GS path in lyx.bat, did you add the path to the lib > directory as well as to the bin directory? Yes I did. > > I'm giving up and going back to use version 1.4.1. > > Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I > just hope this problem does not recur when we get to 1.5 and there is > some "must have" new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo
LyX 1.4.2, Aspell and second languages
Hi, Under Win XP, I have Aspell loaded in C:\Aspell, including the German (de_DE) dictionaries. In the LyX 1.4.2 settings, I have de_DE listed as the alternate language. (The preferences file has \use_alt_language true \alternate_language "de_DE" in it.) However, if I try to spell-check a document, LyX pops up a complaint that no word lists can be found for the language "de_DE". LyX 1.4.1 has no problem spell-checking the same document. Is there some extra incantation I need to do somewhere to get 1.4.2 to use the German word lists? Thanks, /Paul
aspell / problems with umlauts
Hello on the list! I have a problem concerning aspell: The document I write is in English, but my university wants me to write some paragraphs in German. OK, I select them, change the language accordingly, installed the aspell-de package and check the spelling. Words containing an umlaut (äöü) are not properly recognized, e.g. the word "für" is suggested to be replaced by "für". Accepting the replacement leads, in turn, to an "unrecognized word" error. Can anyone please give me a hint what to tweak in order to get it running ...? Thanks in advance! Cz. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Postscript preview
LB wrote: Thank you Paul for all your help. Adding path to GS in lyx.bat did not solved the problem. I have this feeling that the problem is somehow related to the postscript commands inside the figure... I don't know much about Postscript, but I looked in your test.ps file a few days ago and did not see anything that looked like it had the potential to conflict with anything in the environment. When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? The path to the bin directory would not seem to be an issue, since GS runs (enough to hang open, at any rate). I thought maybe if the lib directory were not on the path, GS might have trouble finding a library file. (Seems unlikely, but then the entire bug passed through 'unlikely' on its way to 'impossible' a while ago.) I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some "must have" new feature. I'm going to post this to the developer list, just in case someone recognizes what's going on. /Paul
Re: Postscript preview
Thank you Paul for all your help. Adding path to GS in lyx.bat did not solved the problem. I have this feeling that the problem is somehow related to the postscript commands inside the figure... I'm giving up and going back to use version 1.4.1. Cheers Leo One other difference I notices is that I have the Ghostscript bin and lib directories on my system command path, and you don't. You must have them (as do I) in LyX Tools->Preferences...->Paths->PATH prefix, which LyX attaches to the command path when it shells out to a script. (In my case, they end up on the path twice, which is harmless.) I don't suppose that adding them to your path fixes the bug? (An easy way to try this on a temporary basis would be to add the line SET PATH=C:\\bin;C:\\lib;%PATH% to the lyx.bat file, prior to the start command.) I have no idea how a couple of environment variables and the length of the path to the target file can be interacting, other than if they're both being written to a common buffer somewhere (which is overflowing), and that seems rather unlikely given that I would be putting more stuff in the buffer and not seeing the problem. /Paul
Re: Abnormal behaviour of "greyed out note"
Am Freitag, 28. Juli 2006 17:08 schrieb Nicolás:
> However, when I do the same in a paragraph with Itemize style the result
> in DVI is the following:
>
> "First part of my paragraph
> - note's text in grey (in new line and with '-' in front)
> rest of the paragraph"
>
> Is this the intended behaviour? If so, why it is not this way with
> Standard style?
Does it work if you export to latex, replace the line
\newenvironment{lyxgreyedout}{{\color[gray]{0.8}}{}}
in the preamble with the lines
\def\lyxgreyedout{\textcolor[gray]{0.8}\bgroup}
\def\endlyxgreyedout{\egroup}
and run latex manually on the exported file? If not, please attach an
example .lyx file to the bug at
http://bugzilla.lyx.org/show_bug.cgi?id=2723
> Select the paragraph style and write a title. Press return. At the
> beginning of the following line insert a Greyed out note.
>
> In the resulting DVI it is not only the note in grey, but also the
> paragraph's title.
I filed that in bugzilla: http://bugzilla.lyx.org/show_bug.cgi?id=2723
Georg
Re: 1.4.2 pdflatex viewing problem
"open" in the viewer field seems to do it. That seems a bug and has not been an issue in the previous versions. Lyx OSX should respect the default pdf viewer app as it has. Thanks for the help... Ray
Re: please consolidate the documentation
Helge Hafting wrote: On Fri, Jul 21, 2006 at 12:08:48AM +1000, John Pye wrote: I don't think that we should expect people to use LyX as their documentation browser. Sure, LyX is not my choice for a browser. But documentation for LyX itself is a special case, see below: Operating systems all provide good standard ways of accessing help: Installed LyX documentation should play nice with those so that there's one less thing for new users to learn. Well, supplying LyX docs in pdf and html is nice, of course. Still, the main format for LyX documentation must be LyX files. LyX is supposed to be a document processor good for just this sort of documents, so using anything else would show a worrisome lack of confidence in our own software. The User's Guide is a nice showcase for what can be done with LyX, and it is a quick demonstration of how well LyX handles long documents. (It is quite a few pages, and for demonstration purposes, try copy-pasting the entire thing several times . . . no crash.) Helge Hafting I can't imagine first writing LyX documentation in any other format than .lyx. Most people don't read the docs first, but turn to them when they need to find solutions. So suppose they want to know what the User's Guide has to say about "margins". Do you think that the LyX: Find & Replace has been designed for the purpose of finding information for solving problems or as an editing tool? The .pdf format doesn't normally allow editing of the content so searching is designed for finding keywords to solve problems with a more evolved interface. Because LyX can serve in this capacity doesn't mean it is optimal in comparison to a tool made for this purpose. I think a fair estimate is that the documentation is initially read by people who have not learned that it is cost effective to read the documentation first, and that a huge majority of users will be reading and searching for keywords while troubleshooting. I think the strength of LyX is that it can convert from the .lyx format to *other* user preferred formats which might have small features like a magnifying glass for reading the small print of a diagram, which isn't (AFAIK) included in LyX because it has so little application to the focus of LyX. The Windows LyX display is only about 90-95% of the quality of LyX displayed on Linux or Cygwin, which is another small reason to convert it to a format that maintains quality equality for longer readings. It can be said that a user could glean some information by inspecting the structure of a LyX guide self-referentially gathering some visual clues. This seems to be a strength of using LyX for reading documentation when compared to a pdf reader. But if you compare LyX to the Visual FAQ by Scott Pakin, tug.ctan.org/tex-archive/info/visualFAQ/ , you will see a tool designed for a function LyX stretches to fill. LyX is like a pair of pliers that can be pressed into doing the job extemes of a couple of different size wrenches like the Visual FAQ, and Reader with its advanced search options. > LyX is supposed to be a document processor good for just this sort > of documents, so using anything else would show a worrisome lack > of confidence in our own software. I think the claim that Lyx is the best tool for creating help guides etc. is not the same claim as that LyX is the best tool for reading such documents it creates, and matches or surpasses a mature pdf reader which is dedicated to displaying and searches. The subject: please consolidate the documentation, is I think motivated by difficulty in finding a solution to some problem. If the Wiki were converted to one huge .lyx file, I doubt that it would be that helpful, though you could do time consuming searches for some keyword, if the user knew the right keyword. Building a faster internal storage of keywords found on the Wiki will not be so useful to the new user, but will more serve the experienced user who knows what concept to look for. So a detailed back of the book type index is in a more usable format than a list of words and their locations produced by the search engine and it is also a faster search. The new user perusing such an index replete with "see" and "see also" opens the door for a serendipitous juxtaposition of chance into design. A few shorter LyX visual faqs, each covering some major topic, with the potential of being merged later, would stifle any complaints about inadequate documentation being too spread out. If wishes were horses, beggars would ride (wishlist), Stephen
Re: re-generating microtype
On Sat, Jul 22, 2006 at 09:55:02PM -0400, mail.k wrote: > Friends, > > I'd like to re-generate the Microtype package (to enable the > pdfadjustinterowrdglue option). > The instructions require me to look at the .ins .dtx files in the > package.cab, edit out the comment: %\betatrue > and then generate a fresh package. Could anyone instruct me how to do > this (especially the last part). > > Thanks, > > > Eran > You may get help for this here, but you have much better chance if you try some latex users forum instead. Helge Hafting
Re: please consolidate the documentation
On Fri, Jul 21, 2006 at 12:08:48AM +1000, John Pye wrote: > Hi all, > > I'd like to say congratulations to all on the re-inauguration of the LyX > documentation team ;-) ! The scattered documentation of LyX has > frustrated me too. I have some thoughts and ideas to mention... > [...] > I don't think that we should expect people to use LyX as their > documentation browser. Sure, LyX is not my choice for a browser. But documentation for LyX itself is a special case, see below: > Operating systems all provide good standard ways > of accessing help: Installed LyX documentation should play nice with > those so that there's one less thing for new users to learn. I think > that the LyX manual should serve as a model example of a well-published > document, with HTML and PDF versions, downloadable in various formats, > etc. It should be the type of end-result document that a person setting > out to write a book or a software manunal with LyX would aspire to > produce, not an exposition of the LyX GUI. > Well, supplying LyX docs in pdf and html is nice, of course. Still, the main format for LyX documentation must be LyX files. LyX is supposed to be a document processor good for just this sort of documents, so using anything else would show a worrisome lack of confidence in our own software. The User's Guide is a nice showcase for what can be done with LyX, and it is a quick demonstration of how well LyX handles long documents. (It is quite a few pages, and for demonstration purposes, try copy-pasting the entire thing several times . . . no crash.) Also, when users see something 'cool' in the User's Guide, they can cut & paste it directly from the LyX file, which gets them going quickly. > There should be a good self-updating HTML version of the LyX manual. > Ideally a local search engine could be installed that would search both > the HTML manual and the Wiki side-by-side with a single installation of > lucene, xapian, swish-e, etc. > Cool, but can you make this work on all the very different platforms that runs LyX? A search engine on the web might be easier to pull off. And of course one should be able to use LyX on a machine that not necessarily have a web browser at all. > We should aspire to the PDF version of the manual being a last port of > call: online searching, CHM, Yelp (under GNOME), etc should be able to > provide nicer and more efficient ways to read and search. Although, > given what LyX is, it's important to produce a good looking PDF to prove > what LyX can do. > > We're meanwhile trying to use LyX for documenting a project I've worked > on: the ASCEND modelling environment. So we're very interested in taking > the right approach here. I'm sure a lot of other writers, especially of > software documentation, must be as well. > The right approach for software documentation depends a lot of the intended users, the platform, and other aspects of the environment in which the software will be used. The perfect approach for one project may therefore be wrong for another. Helge Hafting
