Re: #11148: Recognize .plt as gnuplot file extension
Am 17.05.2018 um 19:18 schrieb LyX Ticket Tracker: #11148: Recognize .plt as gnuplot file extension Comment (by skostysh): Hi Sven, have you tried the LyX Gnuplot example file? It is called "gnuplot.lyx". You might be able to open it by going to File > Open and clicking on the "Examples" button and then opening gnuplot.lyx. Are you able to open it? If so, does it compile for you? Good idea, thanks for the hint, but I get exactly the same error pattern. I don't get a preview of the graphic in the opened lyx view, and I cannot compile it. I still have 2.2.3 installed in parallel, could that cause problems? I'd like to keep it until the transition to 2.3 is complete and verified, but in principle I could uninstall and later re-install it. (Hopefully it also works with the updated Miktex.) thanks, sven
Re: #9568: Multicolumn, fixed width, and decimal-separator-alignment does not compile
Am 16.10.2016 um 16:59 schrieb Jürgen Spitzmüller: Am Sonntag, den 16.10.2016, 16:41 +0200 schrieb Sven Schreiber: The attached Latex file uses the "siunitx" package (which I've never Thank you. I am aware of this package, but it has some disadvantages for our purpose: 2. For proper results, one has to tell siunitx the maximum number of numbers before and after the decimal separator, and it is hard to calculate that from within LyX (this is also the reason why we use our own approach instead of the dcolumn package). OK, this of course complicates things quite a bit. I don't see how the max number calculation would be more difficult in Lyx than in Latex given that the user input is the same, but already in Latex I can see it's a hassle. So I think that it would be a reasonable compromise to have the decimal-aligned columns (and multicolumns) centered only. The rest of the argument between the different devels is a bit difficult to follow, however. What exactly is the disagreement, perhaps someone can summarize the two (or more?) positions? thanks, sven
Re: #9568: Multicolumn, fixed width, and decimal-separator-alignment does not compile
Am 16.10.2016 um 14:18 schrieb LyX Ticket Tracker:
#9568: Multicolumn, fixed width, and decimal-separator-alignment does not
compile
If you show us how to do it in LaTeX, we can implement it in LyX.
OK, you asked for it...
The attached Latex file uses the "siunitx" package (which I've never
used before) to achieve flexibility with respect to the
within-cell-alignment of the decimal-aligned multicolumns.
(If the attachment doesn't make it through this channel please tell me.)
In the attached version you find the line "table-number-alignment =
center," -- you can substitute "left" or "right" there, and it yields
the intended effect for me, namely the whole block of what's in the
three multicolumn rows wanders to the left or to the right, while
staying aligned at the decimal dot.
BTW, the "{c}" part after the three "\multicolumn{2}" thingies is
mysterious to me, changing that to "{l}" or "{r}" didn't seem to have
any effect.
HTH,
Sven
\documentclass{article}
\usepackage{siunitx}
\usepackage{booktabs}
\begin{document}
\begin{table}
\caption{Controlling complex alignment with the {tablenum}
macro.}
\label{tab:tablenum}
\sisetup{
table-number-alignment = center,
table-figures-integer = 4,
table-figures-decimal = 4
}
\centering
\begin{tabular}{lr}
\toprule
Heading & Heading \\
\midrule
Info & More info \\
Info & More info \\
\multicolumn{2}{c}{\tablenum{12,34}} \\
\multicolumn{2}{c}{\tablenum{333.5567}} \\
\multicolumn{2}{c}{\tablenum{4563.21}} \\
\bottomrule
\end{tabular}
\hfil
\end{table}
\end{document}
Re: #9568: Multicolumn, fixed width, and decimal-separator-alignment does not compile
Am 15.10.2016 um 18:29 schrieb LyX Ticket Tracker: * milestone: 2.2.2 => 2.2.3 Comment: LyX 2.2.2 is released. Please check whether this bug should remain targeted to 2.2.3. If not, please retarget. Dear developers, two comments: First, I just checked with the new 2.2.2 (thanks for that!) and my original example file still doesn't compile. So you guys are tolerating a situation where normal usage of Lyx without any hacks can produce "rubbish". This should be fixed ASAP, IMHO (hey, never used two acronyms in a row!), whatever the solution is. Secondly, what do you think about my previous comment in the tracker that the left/right/center alignment choice and the decimal separator alignment choice are independent, so that every combination should be possible? Is this doable in Latex (presumably with a package)? Or is it simply too difficult to implement in Lyx? thanks, sven
Re: #9442: Paste via keyboard shortcut (sometimes) not working on Windows
Am 28.04.2016 um 23:58 schrieb LyX Ticket Tracker: #9442: Paste via keyboard shortcut (sometimes) not working on Windows Comment (by gadmm): There is a patch in #10109 for some copy/paste issues on windows. Would somebody check whether this solves this bug as well? There are two problems: First the bug is not deterministically reproducible, so testing takes time and is never 100% sure. Secondly most people cannot build the Windows version from source I guess. (At least I can't.) Are there nightly builds or something like that? thanks for the efforts, sven
Re: #9442: Paste via keyboard shortcut (sometimes) not working on Windows
Am 22.04.2015 um 23:03 schrieb Scott Kostyshak: > On Wed, Apr 22, 2015 at 4:44 PM, Sven Schreiber wrote: >> Hi, >> today I have consciously experienced the behavior that James had >> described: I cut a paragraph that contained some math insets and when I >> pasted it the math insets were gone and instead the TeX equivalent code >> was pasted as text. >> >> After closing and restarting LyX (not the computer) the problem >> disappeared. That was on Win 7 with Lyx 2.1.3. >> >> thanks, >> sven > > Hi Sven, > > Thanks for the feedback. Can you please post this on the ticket itself? > http://www.lyx.org/trac/ticket/9442 > Done (with some delay...). thanks, sven
Re: #9442: Paste via keyboard shortcut (sometimes) not working on Windows
Hi, today I have consciously experienced the behavior that James had described: I cut a paragraph that contained some math insets and when I pasted it the math insets were gone and instead the TeX equivalent code was pasted as text. After closing and restarting LyX (not the computer) the problem disappeared. That was on Win 7 with Lyx 2.1.3. thanks, sven Am 19.04.2015 um 20:09 schrieb LyX Ticket Tracker: > #9442: Paste via keyboard shortcut (sometimes) not working on Windows > +- > Reporter: svetosch| Owner: lasgouttes > Type: defect | Status: new > Priority: normal | Milestone: 2.1.4 > Component: general | Version: 2.1.3 > Severity: major | Resolution: > Keywords: os=windows | > +- > > Comment (by skostysh): > > Note another related bug, in addition to #8695 (mentioned by the OP), > there is also #9155. >
Re: #9442: Paste via keyboard shortcut (sometimes) not working on Windows
Am 05.03.2015 um 12:13 schrieb LyX Ticket Tracker: Comment (by skostysh): Thanks for taking the time to write this up, sven. Regarding pasting TeX instead of math, this is expected to happen if you paste outside of a math inset. If you start a math inset and then paste, it should be pasted as math. Does that work? Yes I'd say that if pasting works, then this works, too. I was just quoting James's additional comment to make the report complete. You would have to ask him whether this part of his experience is just the expected behavior. My own experience has nothing to do with "wrong pasting", it's about whether it does anything at all or not (-> 'command disabled' message). thanks, sven
Re: #1083: we should have a horizontal scrollbar for wide insets like math and tables
Am 25.09.2013 11:22, schrieb LyX Ticket Tracker: #1083: we should have a horizontal scrollbar for wide insets like math and tables -+--- Reporter: levon| Owner: nobody@… Type: defect | Status: assigned Priority: normal | Milestone: Component: general | Version: 1.4.3 Severity: normal | Resolution: Keywords: | -+--- Comment (by lasgouttes): This bug has been the subject of a GSoC project, where Hashini Senaratne bravely dug into our largely undocumented drawing framework. The git branch gsoc/scroll/master now contains a working implementation of keyboard-based scrolling of wide rows. There is no scrollbar for now, but the hard work is done. This will probably get merged in master (for 2.2?) soon. Sorry for the broad reply-to-all, but I just want to signal that despite some long-standing quirks such as this one, I have been a loyal Lyx user ever since it could be used cross-platform, which still is very important for me as well as for the colleagues (who are especially impressed by the math and table editors). Thanks for the ongoing work! I just scrolled back on http://www.lyx.org/News, and saw that this bug (or call it a feature request) is around seven years old, wow. Thanks, Sven It's also amazing
alternative ways of donating
Hi, I would like to donate some money to the project, but I don't like paypal much. If you want I can explain why, but for now I'll spare you the argument. Would it be possible to do a bank transfer, send a cheque, or something like that instead? As I'm based in Germany, maybe to a bank account of a German developer. Other EU countries would also be relatively easy I guess. I read the Norwegian address on the homepage, but since Norway is not an EU member I'm not sure if that would also work (apart from the fact that it's just an address, not an account number). thanks for your help, sven
Re: ctrl-s with focus in toc panel doesn't work
Richard Heck schrieb: > Sven Schreiber wrote: >> This is on winxp from the "LyX-1.5.0-1-Installer.exe". >> >> When the TOC panel (which I have almost always open now because it's >> so nice, probably the best new feature for me) has the focus and I >> want to save the file via the standard keyboard shortcut, nothing >> happens. I have to click in the editing area of the window before I >> can use ctrl-s. >> >> Shall I open a new bug report? > You should check first if there's an old one. This is a known > problem---that the TOC pane eats shortcuts. > > Richard > I couldn't find a match, so this is now the latest and greatest bug with number 4101, a very nice number I must say... -sven
ctrl-s with focus in toc panel doesn't work
This is on winxp from the "LyX-1.5.0-1-Installer.exe". When the TOC panel (which I have almost always open now because it's so nice, probably the best new feature for me) has the focus and I want to save the file via the standard keyboard shortcut, nothing happens. I have to click in the editing area of the window before I can use ctrl-s. Shall I open a new bug report? thanks, sven
Re: Massive Bug in 1.5.0 according to tabs
Jürgen Spitzmüller schrieb: Sven Schreiber wrote: I had reported this on the user list already for rc2 (http://www.mail-archive.com/[EMAIL PROTECTED]/msg57128.html), but did not pursue it because Uwe also could not reproduce it. Haven't tried 1.5.0 final yet, but it was for real and I don't think it has been fixed. So bug 3969 again? Could you try if the patch I uploaded there cures the problem? http://bugzilla.lyx.org/show_bug.cgi?id=3969 Patch: http://bugzilla.lyx.org/attachment.cgi?id=2067&action=view Sorry I'm not currently in the building-from-source business, and my summer holiday is approaching. Actually with 1.5.0 final I cannot reproduce my earlier problems, either. So maybe this has been fixed after rc2. If not, I will report back. -sven
Re: Massive Bug in 1.5.0 according to tabs
Pavel Sanda schrieb: when you create two documents at once LyX 1.5.0. combines the text from the first window with the text in the second one after you changed it by clicking on the specific tab. DVI is OK. But the text in the second window is mixed up with the first one. i'm not able to reproduce it. can you give precise instructions how to cause it ? pavel I had reported this on the user list already for rc2 (http://www.mail-archive.com/[EMAIL PROTECTED]/msg57128.html), but did not pursue it because Uwe also could not reproduce it. Haven't tried 1.5.0 final yet, but it was for real and I don't think it has been fixed. -sven
Re: Massive Bug in 1.5.0 according to tabs
Pavel Sanda schrieb: when you create two documents at once LyX 1.5.0. combines the text from the first window with the text in the second one after you changed it by clicking on the specific tab. DVI is OK. But the text in the second window is mixed up with the first one. i'm not able to reproduce it. can you give precise instructions how to cause it ? pavel I had reported this on the user list already for rc2 (http://www.mail-archive.com/[EMAIL PROTECTED]/msg57128.html), but did not pursue it because Uwe also could not reproduce it. Haven't tried 1.5.0 final yet, but it was for real and I don't think it has been fixed. -sven
Re: Massive Bug in 1.5.0 according to tabs
Pavel Sanda schrieb: when you create two documents at once LyX 1.5.0. combines the text from the first window with the text in the second one after you changed it by clicking on the specific tab. DVI is OK. But the text in the second window is mixed up with the first one. i'm not able to reproduce it. can you give precise instructions how to cause it ? pavel I had reported this on the user list already for rc2 (http://www.mail-archive.com/[EMAIL PROTECTED]/msg57128.html), but did not pursue it because Uwe also could not reproduce it. Haven't tried 1.5.0 final yet, but it was for real and I don't think it has been fixed. -sven
Re: LyX version 1.5.0 (release candidate 2) is released
José Matos schrieb: > Public release of LyX version 1.5.0 (release candidate 2) > === First of all, great news and thank you all for the big effort! > We expect this to be the last release before 1.5.0, and until the > first stable release only critical bugs and regressions will be > addressed. > So if I understand this correctly, there will be some changes in 1.5.0 final that don't get widespread testing. Why not release other rc's until one is satisfactory and that is then declared the final version, with no further changes? I thought that was the whole point of calling it rc instead of beta. (I'm not in the position to demand anything, as I have never contributed anything to lyx except bug reports. But I have come to depend on it as a tool and therefore I have also become a little paranoid with respect to its stability. I hope you understand.) thanks, sven
Re: math toolbar usability suggestion (tiny)
hzluo schrieb: > Current install version do not have an icon for functions popup. > > I think the patch is on the way. > We now have a functions.xpm for that button. > So you will have a 20x20 button instead of a long string. > > BTW, I think the provided functions.xpm is not > so informative. I made another one. > Please see attached. If anyone wants to test > it, just put it in images\math > I have tested it at normal size and large size. > It looks good at both size. So does this mean the issue is resolved or will it be forgotten unless I file a bug? thanks, sven
Re: tabular lines/borders yet again (was: Re: another (?) table-editing bug)
[re-directing it to the devel list] Georg Baum schrieb: > > If you want progress with this then please think how a configurable system > could work. That does not need any coding in the first step. I am almost > sure that the result will be based on some GUI for creating the default, > and a lyxrc setting or configuration file or template document or whatever > where the actual default is stored. > Once we are at this point it will be easy to implement at least the part > that loads the configuration and change the table dialog to use it, so > people who are really annoyed by the current default just need to fire up > their text editor and can change it. A GUI for comfortably changing these > things can still be done later. > This sounds not too hard, possibly because I'm underestimating the task. But since you've asked, here's my suggestion: The first design issue is: should it be a global default or document-specific? I guess the latter would require changing the lyx file format, so I would stick to global -- less convenient for the user, but more realistic in terms of implementability, and good enough IMHO. So as you said, that implies a new lyxrc part; let's call it \tabular_style_border. I would suggest that a style consists of a name and of a definition (pair of strings). The syntax for the definition: What about denominating the borders by 'h' and 'v' for horizontal and vertical, and indexing in python style, i.e. 0 is the first possible border (before the first row or column), -1 is the last one (after the last row or column), and a colon (:) is for defining ranges. To stick with the python convention, the range would not include the upper bound. If no upper or lower bound is given, every border after or before is included. If some border is indexed several times, that means several drawn lines. Examples: 'h1,h1,v1,h-1' would mean a tabular with a double horizontal line under the headings (first row), a vertical line between the first and second columns, and a horizontal line at the bottom. 'h:2, h-2:, h1' would have the first and last rows enclosed in horizontal lines, where the one under the headings (first row) is doubled. 'v:, h:, h1' would be the current default (if I'm not mistaken). 'h0, h-1, v0, v-1' would enable all outer borders. etc. So much for setting the default in the lyxrc file. Several pre-defined styles could be distributed with lyx, for example: 1. the current default 2. no borders 3. all borders (only single lines) 4. all horizontal lines, no vertical lines 5. all horizontal lines, plus doubled between rows 1 and 2 6. lines after the first row and column respectively, and a line at the bottom The pre-defined styles would have to be stored somewhere of course -- don't know if there's an obvious place for that, or if a new config file is needed. The gui way would add a 'tabular' item in the global settings dialog in the look&feel (German: Aussehen) group. There a user could choose from the list of pre-defined line styles, and there would be a little, say 5x5, schematic tabular next to the drop-down list to visualize the choices. Something like: initial line style for new tabulars: [drop-down-list] (you can always adjust lines later) preview: _| | | | _| Later that dialog could be enhanced by an input field so that a user can add (or load) new styles; but I think it's not needed initially, the "tweaking community" should be satisfied with defining their new styles in a config file for the time being. Users can share their styles on the wiki, for example. This dialog pane for tabulars could later maybe also hold some other table defaults like font styles etc. But that is another story. Ok so much for that. Boy, all I wanted is a better default... Now you guys better get to work ;-) -sven
Re: small glitches
Jean-Marc Lasgouttes schrieb: >>>>>> "Sven" == Sven Schreiber <[EMAIL PROTECTED]> writes: > > Sven> 2. (some) paragraph settings should be disabled for captions: I > Sven> asked on the user list about reformatting captions (e.g., > Sven> flushleft), and it's not implemented. Ok, but then I think the > Sven> corresponding drop-down lists in the paragraph settings dialog > Sven> should be disabled. > > This is > http://bugzilla.lyx.org/show_bug.cgi?id=1550 > > Should be easy to fix. Good ;-) I haven't understood all the comments in that bug, but for captions it indeed seems quite simple, the whole alignment setting should be disabled, disabling specific options is not needed. > > Sven> 3. The first selection in a graphics-file-open dialog isn't > Sven> copied to the selection area. I have to move the selection > Sven> somewhere else and back again to actually be able to click ok to > Sven> insert the graphics. (However, double-clicking works ok.) > > Is it this one? > http://bugzilla.lyx.org/show_bug.cgi?id=1663 > > No, that sounds unrelated. It could be similar to 347, although I don't know if technically it's the same issue... (Wow, that's old!) Thanks, Sven
small glitches
Hi, before flooding bugzilla with new bugs let's see what you have to say about the following minor issues (all with 1.4.3 qt on ubuntu): 1. lyx should not allow backslash in labels: I had math (in latex: $\alpha$) in a section title, inserted a label, accepted lyx naming suggestion including the \alpha, and got a tex error from trying to view it. Since I used only lyx gui tools, I think that's a bug, and lyx should automatically check for backslash (and other problematic characters?) in labels. 2. (some) paragraph settings should be disabled for captions: I asked on the user list about reformatting captions (e.g., flushleft), and it's not implemented. Ok, but then I think the corresponding drop-down lists in the paragraph settings dialog should be disabled. 3. The first selection in a graphics-file-open dialog isn't copied to the selection area. I have to move the selection somewhere else and back again to actually be able to click ok to insert the graphics. (However, double-clicking works ok.) Thank you, Sven
Re: Sudden lose of keyboard input.
Bo Peng schrieb: >> I have lyx 1.4.2 installed on a win2k system. I can not reliably >> reproduce this, but after a few minutes, lyx would not respond to >> keyboard input. Mouse/menu etc still work. All other applications >> (cygwin, firefox etc) still get keyboard input. > > Follow up: > > I can use Alt-F etc to invoke menu and use arrow keys to navigate the > lyx menu (but not moving cursor in the main window). To see if my > keyboard is jammed in any way, I use on-screen keyboard, and lyx still > does not respond. > > It seems to me that this is a bad lyx bug ... how can I debug? > > Bo > Can't really help, but it sounds familiar: with the selection-at-beginning-of-line bug I reported shortly before 1.4.2 (and which was fixed there), I saw similar things happening. Some people actually had a crash, but for me it was more like what you saw. Also on windows, so maybe that's related... -sven
Re: [Fwd: bug?: section numbering in note-insets]
Jean-Marc Lasgouttes schrieb: >> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > Feel free to open a bug where this things can be discussed. Once the > desired behavior is well understood, it should not be too difficult to > implement. > Ok I did that and it's bug 2671 now. cheers, sven
[Fwd: bug?: section numbering in note-insets]
Got no replies on this on the users list, so I'm trying again on lyx-devel. -sven Original-Nachricht Betreff: bug?: section numbering in note-insets Datum: Thu, 15 Jun 2006 14:33:13 +0200 Von: Sven Schreiber <[EMAIL PROTECTED]> An: LyX Users Hi all, when I shove an entire subsection into a note inset, the numbering of the other non-note subsections remains as if nothing was "commented out", i.e. numbers on screen do not match the printed output. I realize that this behavior might also be considered a feature, but I'm inclined to classify it as a bug instead. But I found no matching bugs in bugzilla, although I vaguely remember reading some discussion of that somewhere. So should I open a new bug? (oh btw this is with lyx 1.4.1 on windows) On a related note, isn't part 3.3.9.3 in the User's Guide concerning the comment paragraph environment obsolete now with Lyx 1.4? Cheers, Sven
Re: Lyx 1.4.0pre3 release problems.
samar j. singh schrieb: > 2. Previously we could paste from an excel or gnumeric spreadsheet into the > cells of a Lyx table through a process documented on the wiki at : > http://wiki.lyx.org/Tips/CopyTablesFromSpreadsheets. This no longer works. > That makes it very difficult to transfer data between a spreadsheet and a lyx > table. I would suggest this feature be retained. Absolutely! I found about that feature just recently and now it's going away?? Nooo! I admit the feature is not in the official documentation (afaik) and thus it probably does not officially qualify as a regression, but imho it comes close. By no means do I want to hold up the release of 1.4.0, but could the restoration of that or an equivalent feature be targeted for 1.4.1 please? Should I make a formal bugzilla entry? (Or is the whole thing a misunderstanding?) thanks, sven
1.4 vs. 2.0
Dear developers, I was just looking at the "new in lyx 1.4" page and realized that there are *a lot* of new features. That fact made me think: if this change is from 1.3 to 1.4, when will they ever consider a release to be worthy of version number 2.0? Of course the naming issue is not really important for existing users, but in terms of setting expectations for prospective new users (a.k.a. marketing) I believe it could be worth thinking about before releasing. Or what are you guys up to for 2.0? Include automatic paper-writing? That would be nice... ;-) Cheers, Sven
Re: maybe known bug? lyx 1.3.5 crash
Angus Leeming wrote: > Sven Schreiber wrote: > > >>I suspect this is already known, but I figured a message couldn't hurt. >>The following happened on the windows-port of lyx 1.3.5 (on win 2000). >> >>1) Start lyx >>2) start a new default document >>3) type a character (or whatever) >>4) hit return >>5) choose insert-index entry from the menu (yes I know this doesn't make >>sense) >>6a) wait some seconds and lyx crashes (here at least) >>6b) or quickly cancel the dialog and click with the mouse in the final >>line/paragraph of the document, crash >> >>I see no messages in the accompanying console window before it is closed >>automatically. > > > I can't make it crash (using LyX 1.3.6cvs), but equally I see nothing to > indicate that a bug has been squashed in status.13x > > http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/Attic/status.13x?rev=1.1.2.260&only_with_tag=BRANCH_1_3_X&content-type=text/vnd.viewcvs-markup > ( Equivalent URL: http://tinyurl.com/7n38j ) > > Perhaps you might grab the LyX 1.3.6 pre-release from > http://wiki.lyx.org/Windows/LyX136pre and see if you can make that crash? > If so, could you file a bug report at http://bugzilla.lyx.org ? > > Thanks, Interestingly, the same steps crash 1.3.5, but not 1.3.6pre22! Good work (again)! -sven
maybe known bug? lyx 1.3.5 crash
I suspect this is already known, but I figured a message couldn't hurt. The following happened on the windows-port of lyx 1.3.5 (on win 2000). 1) Start lyx 2) start a new default document 3) type a character (or whatever) 4) hit return 5) choose insert-index entry from the menu (yes I know this doesn't make sense) 6a) wait some seconds and lyx crashes (here at least) 6b) or quickly cancel the dialog and click with the mouse in the final line/paragraph of the document, crash I see no messages in the accompanying console window before it is closed automatically. cheers, sven
Re: Remaining LyX 1.3.6 bugs
Angus Leeming wrote: > Sven Schreiber wrote: > >>I think Uwe's right, my brief experimentation showed that ghostview >>actually stops working "earlier" (= already with shorter paths) than >>miktex/yap, when used to open an eps-file with a long path directly. >>I even couldn't reproduce the yap-crashes with any file with a path >>that the windows-explorer still accepted. >> >>So save your energy for other bugs ... > > > So, here's your chance to earn $500 if the bug still exists with > Ghostscript 8.51. See the "Ghostscript Bug Bounty program" at > http://www.ghostscript.com/ > > Please try it (gs 8.51) out and let us know whether it works or not. > Thanks for trying to earn me money, but I think that's for squashing the bugs, not reporting them... And it seems it's the ghost_view_ frontend that crashes, not ghostscript itself (8.50 btw), since yap works and somebody said it uses the gs libs. So nothing really for me to do I'm afraid. -sven
Re: Remaining LyX 1.3.6 bugs
Uwe Stöhr wrote: > > I would do this but the Problem with Yap is not a bug in LyX. > Windows has a character limit for filenames. If you use a filename with > 220 chars, export the LyX document to .tex, run then LaTeX, and open the > created file with yap no crash occurs. If you view the DVI from within > LyX yap crashes because the dvi file uses then the path > > PSfile="F:/lyxdokumente/lyx/tmp/lyx_tmpdir1060a00924/lyx_tmpbuf0/_lyxdokumente_FILENAME.eps > > > (where FILENAME has 220 chars) and this is too long for ghostscript and > Windows. (Yap uses ghostscript libraries to show eps-files in dvi.) > You can also see this when you use the maximal char number for the > filename in Lyx. Then convert.exe fails to convert the image to ppm as > convert also uses ghostscript. > > But anyway, who uses such long filenames? Should we take care about > this? If yes, we could limit the filename length allowed for LyX to 100 > chars or so, but I don't think this solves the problem in general. > > regards Uwe > I think Uwe's right, my brief experimentation showed that ghostview actually stops working "earlier" (= already with shorter paths) than miktex/yap, when used to open an eps-file with a long path directly. I even couldn't reproduce the yap-crashes with any file with a path that the windows-explorer still accepted. So save your energy for other bugs ... Again, thanks for the great work, lyx-win will be/is cool. -sven
Re: [1.3.6pre19] Various problems displaying graphics
Angus Leeming wrote: >>In an existing Beamer presentation (works fine with 1.3.5) containing >>.pdf and .png graphics, calling View->PDF (pdflatex) gets me a half >>dozen error messages, all "Unknown graphics extension: .XXX" where XXX >>is either pdf or png. > > > Known problem. Fix imminent. Let's see how many of the other problems you > describe disappear at the same time. > Just installed win-136pre20 and my document with pdf-graphics now compiles fine with pdflatex. (Haven't tested the "other problems".) However, the resulting pdf is not opened automatically due to missing viewer entries in preferences. I believe (but I'm not sure) that this configuration was automatically set up in earlier lyx-win versions? Or do I need to formally uninstall earlier versions? The computer has ghostview/script and a full (more-than-reader) acrobat package. cheers, sven
known bug? 1.3.6win-pre19 pdflatex graphics
I just installed the shiny new windows version -- thanks again for all the effort that has been put into it and sorry that I couldn't join the testing earlier due to family events. The install went well, all looks great, but pdflatex export/view doesn't work with included .pdf-files as graphics. (error message "unknown extension...") >From another thread that I read it seems that this is already known behavior, right? If I can be of any help with investigating/testing this issue, please tell me what experiments would be useful to get a clue on the solution. cheers, sven
Re: tex2lyx + international characters = redundant braces in lyx (1.3)?
Angus Leeming wrote: >> >> (No need to respond if this is a totally stupid/unrelated question, I >> will get the subtle hint... but here goes:) >> Aren't all western characters (iso-8...whatever) supported by lyx? > > Does this answer your question? Yes and no, it answered a lot, but the misunderstanding I had was much more basic: I simply wasn't aware that oe-lig is not officially "western" (in contrast to the danish ae-lig, for example). Thanks!
Re: tex2lyx + international characters = redundant braces in lyx (1.3)?
Jean-Pierre Chrétien wrote: > Georg Baum <[EMAIL PROTECTED]> writes: > > > >>Does LyX support \oe and \OE natively? If yes, we should convert \oe to the >>native format (an inset?), if not we should leave it alone. > > > I'm not aware about native support in 1.3.5 (otherwise I would use it). > So leave it as is. > (No need to respond if this is a totally stupid/unrelated question, I will get the subtle hint... but here goes:) Aren't all western characters (iso-8...whatever) supported by lyx?
tex2lyx + international characters = redundant braces in lyx (1.3)?
Hi, I just stumbled over what I think is a little quirk in tex2lyx. When
I convert a file that contains {\ss} latex codes, using the tex2lyx -
lyx2lyx - lyx 1.3.5 procedure from the wiki (on windows), the braces
appear as ERT in the final lyx file, although they are redundant.
The braces don't do any harm, they're only redundant.
Example: the latex input So{\ss}e should appear as Soße in the lyx file.
(Hope the German es-zett is preserved in the mail.) What appears is:
So{ß}e.
Tried to workaround with So\ss{}e, which gives
Soß{}e (still two different ert insets)
So is it possible for tex2lyx to recognize a pair of braces that simply
serves to delimit latex codes from surrounding text, and remove them in
the lyx file? That would be great.
Btw, note that all the {\ss} in the input file were caused by the WinEdt
(very popular windows latex shell) function to automatically save
non-ascii input as ascii-latex-codes. So I guess this (minor) problem
may appear more often in the future when lyx on windows is more
widespread, and many people want to import their non-English latex files
into lyx.
cheers,
sven
Re: lyx-crash w/ file that it itself created --solved
(sorry for new thread, btw is it possible to reply to the gmane-transferred mail, I mean are list addresses resolved etc?) Jean-Marc Lasgouttes wrote: Sven> "Can't change number of columns in 'simple'" You have entered a & in a formula, and that confuses LyX. This bug ill be fixed in 1.3.6, but in the meantime, you need to edit the lyx file with a text editor and find the formula... JMarc Ah, that spells relief! You were absolutely right, thanks a lot! -sven
lyx-crash w/ file that it itself created (urgent user problem)
Hi, I have a weird show-stopping problem, and I need the output from the lyx-file tomorrow for a presentation. Any hints would be highly appreciated! (This is with Ruurd's lyx 1.3.5 on win2000 -- if all fails within the next few hours I will try at home on linux, but I'd rather have a quick fix now.) I am working on a file using the "beamer"-class. No problems with other beamer-files, including the backup version of last night. So the cause must be in a change I did yesterday, although I didn't have any problems with lyx while working on the file. When I try to open that file (from lyx-open dialog, or by double-clicking), lyx reproducibly crashes (already tried a win-reboot, and lyx reconfigure) and gives me the following message on the console window: "Can't change number of columns in 'simple'" The possibly relevant changes that I can remember since the last working file version are a) creating an equation-array with control-return (?) in display formula b) changing the "depth" in item lists c) changing a "BeginFrame" to "BeginPlainFrame" Anybody's got a clue? TIA sven
Re: latex -> tex2lyx -> lyx2lyx -> lyx1.3 conversion report
Georg Baum wrote:
(please cc me if needed, the users list is enough for me)
I did it this time, but will propably forget that in the future. Consider
using the news <-> malilinglist gateway http://gamne.org if you don't want
to subscribe. The group name is gmane.editors.lyx.devel.
Alright, will do that.
Please provide an example. What shall we do if we don't have one? This is
probably a known problem with minipages.
Here's one, and it's actually worse with the new wiki-version of tex2lyx
and lyx2lyx than before (Angus' snapshot two weeks ago), because now it
doesn't compile from lyx (1.3) anymore (gives me 18 errors, two weeks
ago it just produced overlap of the date and the minipages; compiles
fine in latex):
\documentclass{article}
\begin{document}
\title{The\thanks{versions}}
\author{
\begin{minipage}[t]{6cm} \centering Schreiber\footnote{Goethe}\\[0.5cm]
\rule[-3cm]{3cm}{3cm}
\end{minipage}\hspace{1cm}
\begin{minipage}[t]{6cm} \centering Wolters\footnote{Freie}\\[0.5cm]
\rule[-3cm]{3cm}{3cm}
\end{minipage}}
\date{2004}
\maketitle
\end{document}
The resulting lyx files are too long to paste here. Maybe the
intermediate file for lyx-1.4 works with 1.4?
Also, maybe somebody could indicate what exactly the known problems with
minipages are so that my testing is more useful, instead of reproducing
known bugs over and over again.
Good luck debugging,
Sven
latex -> tex2lyx -> lyx2lyx -> lyx1.3 conversion report
(please cc me if needed, the users list is enough for me)
Angus Leeming wrote:
Can I suggest that you post minimal latex files of any construct that you
find aren't handled well to the lyx-devel list.
There weren't that many things left (as opposed to the
relyx-conversion), and some are known issues according to Georg (Baum).
The rest were minor issues -- oh, and keep in mind this is with Angus'
tex2lyx-win-snapshot from 2 weeks ago, and result is the combined
working of tex2lyx and lyx2lyx to open with lyx 1.3.5:
- imports the \thanks-field inside the \title as ERT (imho should be
converted to a lyx-footnote which does exactly the right thing for me)
- has problems with my complicated \author-field which causes the
pdflatex-output to be different from the original before conversion
(graphics and text overlap; can't blame it too much, this includes
minipages) -- sorry, don't have time right now for a minimal example
with the new tex2lyx, but will be happy to do that if needed.
- \vspace{} is sometimes left as ERT and sometimes converted to
lyx-native "space above", should be consistently done
- I used ".\" in the latex file after abbreviations (e.g.: "e.g.\") to
tell tex not to insert to much space/stretch after it. In lyx this is
ERT, although I guess lyx has a native mechanism for that?
- \pagebreak is left as ERT, could be converted I guess
- minipage again: a relatively complicated page with lots of minipages
is not output properly, some overlap is happening
happy hacking and thanks for your work,
sven
startup crash on ppc for me, too
Hi, I'd like to follow up on a message from Nirmal Govind reporting problems with lyx 1.3.0 on the PowerPC platform (Qt frontend). My system is the ppc redhat port called yellow dog linux (current release 2.3 with updates installed). Both the src.rpm and the tarball compile seemingly fine, but at startup Lyx crashes with the sigsegv signal. Earlier releases mostly even failed to compile, as far as I remember, with the exception of 1.2.1 which I got working (compile&startup) after trying many xforms install variations (it's not part of the distro). Hope there's future for Lyx on ppc! Thanks Sven
