Re: Will LyX 2.2 fix the OS X slow scrolling problem?
Scott Kostyshak writes: > On Wed, Jun 3, 2015 at 10:46 AM, Jean-Marc Lasgouttes > wrote: >> Le 03/06/2015 02:26, Jerry a écrit : >>> >>> Will LyX 2.2 fix the OS X slow scrolling problem? >>> >>> Someone mentioned some time back that there is an experimental fix >>> for the slow scrolling problem on OS X LyX but that it needs testing. >>> I am willing to test. However, even further back while testing for >>> another problem, I experienced difficulty building from source and >>> the problems were not resolved (for me) so I abandoned those earlier >>> efforts. >> >> >> Hi Jerry, >> >> Current master code (that will become 2.2) should indeed improve greatly the >> MacOS experience: faster, with proper kerning and retina support. >> >>> If someone can either provide a binary or provide some dumb-guy-level >>> instructions for checkout and building, I would be happy to take it >>> from there. I already have git installed and can do a basic >>> checkout. >> >> >> I'll let Stephan answer on what is the easiest way to build from scratch on >> Mac OS. > > I know almost nothing about Homebrew, but would it make sense to have > a homebrew script? Oh - LyX is in homebrew cask, i.e. the OS X installer. So I don't know if they would include a LyX recipe. Rainer > > Scott > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: Will LyX 2.2 fix the OS X slow scrolling problem?
Scott Kostyshak writes: > On Wed, Jun 3, 2015 at 10:46 AM, Jean-Marc Lasgouttes > wrote: >> Le 03/06/2015 02:26, Jerry a écrit : >>> >>> Will LyX 2.2 fix the OS X slow scrolling problem? >>> >>> Someone mentioned some time back that there is an experimental fix >>> for the slow scrolling problem on OS X LyX but that it needs testing. >>> I am willing to test. However, even further back while testing for >>> another problem, I experienced difficulty building from source and >>> the problems were not resolved (for me) so I abandoned those earlier >>> efforts. >> >> >> Hi Jerry, >> >> Current master code (that will become 2.2) should indeed improve greatly the >> MacOS experience: faster, with proper kerning and retina support. >> >>> If someone can either provide a binary or provide some dumb-guy-level >>> instructions for checkout and building, I would be happy to take it >>> from there. I already have git installed and can do a basic >>> checkout. >> >> >> I'll let Stephan answer on what is the easiest way to build from scratch on >> Mac OS. > > I know almost nothing about Homebrew, but would it make sense to have > a homebrew script? Yes - but you need somebody to make one and to maintain it. Cheers, Rainer > > Scott > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [ANNOUNCE] LyX 2.1.3 Released
Rainer M Krug writes: > For Mac: > > I just updated LyX on homebrew cask [1] to 2.2.3 Sorry - I was ahead of my time. Should have been 2.1.3 Rainer > > Cheers, > > Rainer > > > Richard Heck writes: > >> We are proud to announce the release of LyX 2.1.3. This is the third >> maintenance release in the 2.1.x series. >> >> LyX is a document processor that encourages an approach to writing based >> on the structure of your documents and not simply their appearance. It is >> released under a Free and Open Source Software license. >> >> You can download LyX 2.1.3 from http://www.lyx.org/Download/. >> >> LyX 2.1.3 is the result of on-going efforts to make our stable version >> even more reliable and stable. We have fixed a number of bugs and made >> a number of improvements. These are detailed below. We strongly encourage >> all LyX users to upgrade to this version. >> >> If you think you have found a bug in LyX 2.1.3, open a bug report at >> http://www.lyx.org/trac/wiki/BugTrackerHome. If you're not sure whether it >> really is a bug, you can e-mail the LyX developers' mailing list (lyx-devel >> lists.lyx.org) and ask. >> >> If you have trouble using LyX or have a question, consult the >> documentation that comes with LyX and the LyX wiki, which lives at >> http://wiki.lyx.org/. If you can't find the answer there, e-mail the LyX >> users' list (lyx-users lists.lyx.org). >> >> We hope you enjoy using LyX 2.1.3. >> >> The LyX team. >> http://www.lyx.org >> >> >> What's new >> == >> >> ** Updates: >> *** >> >> * DOCUMENT INPUT/OUTPUT >> >> - Add support for some conference poster classes (a0poster, beamerposter, >> sciposter) (bug 8714). >> >> - Add support for the sectionbox and tcolorbox packages (part of bug 8714). >> >> - Add support for PDF annotations (via pdfcomment package) (bug 6975). >> >> >> * TEX2LYX IMPROVEMENTS >> >> - Support for bibliographies using the package bibtopic. >> >> - Support for textual references (LaTeX-command \namref from the package >> nameref). >> >> - Support for items in itemize environments that have an optional argument. >> >> - Support for the math font of the Iwona and Kurier font families. >> >> - Support for the Libertine fonts. >> >> - Support for a relative length as paragraph separation. >> >> - Support for relative lengths in horizontal and vertical spaces. >> >> - Support for glue lengths in horizontal and vertical spaces. >> >> >> * USER INTERFACE >> >> - References no longer truncated in outliner (bug 9312). >> >> - Allow computing selected subformulas with computer algebra systems. >> >> - Number correctly footnotes in title layouts (part of bug 2666). >> >> - Ctrl+A is now bound to inset-select-all, which does a local >> selection (current inset) and grows at each new invokation. Try it! >> >> - Debug options in message pane are now sorted alphabetically. >> >> >> * DOCUMENTATION AND LOCALIZATION >> >> - New example file "PDF-comment.lyx" describing the support for PDF >> annotations. >> >> - Updated Arabic, French, German, Japanese, Portuguese, Slovak and Swedish >> user interface localization. >> >> >> ** Bug fixes: >> * >> >> * DOCUMENT INPUT/OUTPUT >> >> - Fix crash on exporting a recursive math macro (bug 9140). Recursive macros >> are invalid, so typesetting will still fail with "TeX capacity exceeded". >> >> - Fix baseline calculation in last paragraph (bug 9231). >> >> - Fix export of xfig external insets (bug 9244). >> >> - Fix incorrect output of ampersands when multiple keys are given for a >> citation (bug 9296). >> >> - Output package options (specified with PackageOptions layout tag) >> before loading any potentially affected package (bug 9355). >> >> - Fix export of documents that use the LaTeX-packages mhchem and wasysym >> (bug 9266). >> >> - Remove unnecessary preamble code in LaTeX export of documents using the >> class REVTeX 4.1 file (bug 4625). >> >> - Fix for improper environment with duplicate PATH variable entries. >> This happens on Mac OS X 10.10 (Yosemite) where launchd(8) passes >> such an environment to LyX when started from the dock (bug 9317). >> >> - Protect insets when needed in subfloat captions (bug
Re: View/compile reduced size PDF within LyX
Liviu Andronic writes: > On Thu, Feb 12, 2015 at 9:41 AM, Rainer M Krug wrote: >> Liviu Andronic writes: >> >>> On Tue, Feb 10, 2015 at 12:04 AM, James wrote: >>>>> >>>> >>>> On a similar note, AFAIK most of the size reduction comes from Ghostscript >>>> reducing the size of the raster images and those with raster components. >>>> The >>>> next level of usability (beyond using a converter on a whole document) >>>> would >>>> be to have an option within the figure float setting or graphic dialogue >>>> box >>>> that gave a second option for "draft mode" (i.e. an option that still >>>> included the image, but at a draft appropriate resolution if a reduction is >>>> possible for that graphic). >>>> Of course, there would then be a need for a method to un-select all >>>> graphics >>>> with the option selected in bulk for final compilation. >>>> >>> IMO this would be messy (and ineffective). Nicer would be a >>> dedicated Document > Settings option that would allow to choose a >>> specific downscaling level, and that LyX would honor at compile time. >>> If this is feasible, this would avoid adding new converters in File > >>> Export. But this solution is more involved than simply adding an >>> additional converter... >> >> This would not be messy, if one would also have a document wide option >> with the possibility to set all image specific values. >> >> This would be similar to e.g. PowerPoint (at least it was when I last >> used it about 10 years ago...). You can set a "reduced size" for each >> image, or for the whole document. >> >> Advantage: you can have graphs in full resolution, but images reduced. >> >> Main difference: the reduction in size would be done by the image >> copiers. >> >> Now let's think further: >> > > >> In my case, I have quite often huge vector graphs (pdf), as they contain >> hundreds of thousands of points. Now these are easy to generate in R and >> also quite easy to view for themselves, but they can cause problems with >> displaying (and size I guess if there are to many points). In these >> cases, an option to convert the vector graph to an image of a given >> resolution (the one used for the target resolution above?) would make >> life much easier. >> > > I think this sounds interesting. Maybe worth opening a feature request > on Bugzilla. Done - http://www.lyx.org/trac/ticket/9405 Thanks, Rainer > > > Liviu > > >> Cheers, > >> > >> Rainer >> >> >>> >>> Liviu >> >> -- >> Rainer M. Krug >> email: Rainerkrugsde >> PGP: 0x0F52F982 -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [ANNOUNCE] LyX 2.1.3 Released
; - Maintain paragraph settings (alignment etc.) when importing chunk layouts > (bug 9320). > > - Fix export to LyX 2.0 of chunk insets without optional argument (bug > 9343). > > - Fix import of ERT beamer block titles which are preceeded by a > language switch. > > - Fix and simplify paragraph params parsing in get_containing_layout. > > > * USER INTERFACE > > - Fix alignment rendering of multirow in LyX (bug 8976). > > - Fix mapping of ISO_Left_Tab key, which was erroneously assigned to Tab > (instead of BackTab). > > - Disallow to insert program listings to footnotes and margin notes > (bug 9321). > > - Fix computer algebra system computations in formulas with '=' signs. > > - Fix rendering of \varOmega on OS X (bug 7954). > > - Only allow 1 paragraph in footnotes when they are part of a title > layout (bug 2666). > > - When switching classes, warn user about all unapplied document changes > (1. part of bug 9356). > > - When adding a module, warn user about all unapplied document changes > (2. part of bug 9356). > > - Do not enable the Apply button in the document dialog just because a > module was selected in the widget (without actual change) (bug 9365). > > - Fix logic of "Maintain aspect ratio" checkbox in the graphics dialog > (bug 9357). > > - Fix most frequent reason for crash while editing with open view source > window (bug 9336). > > - Fix crash when pasting citation into math formula (bug 9302). > > > * INTERNALS > > - Fix wrong test in LyX server. > > - Fix possible memory corruption on copying to the clipboard. > > - Fix possible memory corruption during LaTeX log file parsing. > > - Make some math messages translatable (bug 1908). > > > * DOCUMENTATION AND LOCALIZATION > > - Fix language settings for all IEEEtran templates (bug 9350). > > - The template document for REVTeX 4.1 has been rewritten. > > > * LYXHTML > > - Fix export of \ll, \gg, \ne and \neq in math formulas (bug 9372). > > > > * TEX2LYX > > - Do not ignore table columns with unknown column specifiers (bug 9311). > > - Parse tikzpicture environment correctly (bug 9011). > > - Fix misparsing of \textgreek without polyglossia (bug 8553). > > - Parse post command argument insets (bug 8473). > > - Parse parsing of verbatim options containing commands (bug 9113). > > > > * BUILD/INSTALLATION > > - Fix some compiler warnings. > > - Fix a few minor issues in the RPM spec file template (bug 9349). > > Footnotes: [1] https://github.com/caskroom/homebrew-cask -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: View/compile reduced size PDF within LyX
Liviu Andronic writes: > On Tue, Feb 10, 2015 at 12:04 AM, James wrote: >>> >> >> On a similar note, AFAIK most of the size reduction comes from Ghostscript >> reducing the size of the raster images and those with raster components. The >> next level of usability (beyond using a converter on a whole document) would >> be to have an option within the figure float setting or graphic dialogue box >> that gave a second option for "draft mode" (i.e. an option that still >> included the image, but at a draft appropriate resolution if a reduction is >> possible for that graphic). >> Of course, there would then be a need for a method to un-select all graphics >> with the option selected in bulk for final compilation. >> > IMO this would be messy (and ineffective). Nicer would be a > dedicated Document > Settings option that would allow to choose a > specific downscaling level, and that LyX would honor at compile time. > If this is feasible, this would avoid adding new converters in File > > Export. But this solution is more involved than simply adding an > additional converter... This would not be messy, if one would also have a document wide option with the possibility to set all image specific values. This would be similar to e.g. PowerPoint (at least it was when I last used it about 10 years ago...). You can set a "reduced size" for each image, or for the whole document. Advantage: you can have graphs in full resolution, but images reduced. Main difference: the reduction in size would be done by the image copiers. Now let's think further: In my case, I have quite often huge vector graphs (pdf), as they contain hundreds of thousands of points. Now these are easy to generate in R and also quite easy to view for themselves, but they can cause problems with displaying (and size I guess if there are to many points). In these cases, an option to convert the vector graph to an image of a given resolution (the one used for the target resolution above?) would make life much easier. Cheers, Rainer > > Liviu -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: Double word bug - LyX is duplicating random words
James Smith writes: > Jean-Marc Lasgouttes Sun, 01 Feb 2015 14:44:19 -0800 > > That's terribly weird. Could this be completion playing tricks? > Although I do not see this happening.Can you give us details (LyX > version, platform...). We never had a report like this one.If you want > to find all these occurrences in your document, I guess it is possible > with advanced search and replace and regular expressions. > > Using a regular expression worked well a treat to find the double words. I > had a feeling I could programmatically use the feature but didn't know how > to implement the search like that. > > I have now removed all that were in the master document and will now see if > I can trace when and how any new occurrences are introduced. > > For others reference, the way to find double words in the Advanced Find and > Replace is with a user defined regular expression that contains: > > [[:space:]]([[:alpha:]]+)[[:space:]]\1[[:space:]] > > The code was found buried in the 2.1.1 User guide. > > Re. The actual double word bug. > I'm updating to LyX 2.1.2 and hoping that the bug has been inadvertently > fixed. > But if it hasn't, now that I have been able to find the double words and > remove them I should be able to tell if the duplication is related to new > keystrokes or whether it is the bug is more spurious. Please correct me if I am wrong: I assume that if auto-correct or auto-complete is the cause, you should see certain words being duplicated, while if it is something else, it might be random words. So knowing which words they are, might be useful in finding out what caused it? Rainer > > Cheers > James -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [PATCH] LyX HiDPI support in OS X with Qt 5
Stephan Witt writes: > Am 14.10.2014 um 09:15 schrieb Rainer M Krug : > >> Let me chime in here as a non-lyx-programmer, but lyx user on a mac. >> >> I am sure there is a lot of interest among mac users for this patch. I >> also understand that it is not yet in a usable state, but when it is, >> would it be possible to make an unofficial dmg for mac users, so that >> this can be tested widely? As I understand, not many active developers >> of lyx are mac users, so a dmg would enable a much wider audience to >> test this. If it is only available as source, I don't thnik many mac >> users would compile it, unless it is put on homebrew… > > Hi Rainer, > > you're right. I thought I'll provide an unofficial disk image with retina > support until the release of a final retina ready version is done. Great - sounds good. > That was my plan already, but... There is always a *big but* in the end ... > > This feature requires Qt5 and LyX gets Qt5-support with 2.2.0. That's a > problem. Finally it's not only the question if retina-support is ready - > that's possible in reasonable time. The question is: when is it possible > to make a 2.2.0 release! Currently there isn't even a maintainer for it. > > Therefore this disk image with retina support will be something like a > unofficial release - I'd guess many Mac users are tempted to try it out > and then they don't want to go back - not even for production! This might be risky. To see if the retina support is ready, one option would be to disable e.g. the save function and make it visible in the running instance that it is for testing the display issues *only* and *not* for production? Cheers, Rainer > >> Scott Kostyshak writes: >> >>> On Mon, Oct 13, 2014 at 7:38 AM, Stephan Witt wrote: >>> >>>> I'm trying to verify my changes on Linux. >>> >>> Thank you! >>> >>>> What are others doing to build LyX with Qt5 on Linux? >>> >>> You can see my build script here: > > Thank you for the pointers. > >>> >>> https://github.com/scottkosty/lyx-tester/blob/master/lyxbuild >>> >>> If you want, you can have a completely automatic installation of >>> dependencies and building of LyX starting from a fresh Ubuntu >>> installation with one command: >>> https://github.com/scottkosty/lyx-tester >>> I only recommend that on a virtual box though. It has not been tested >>> except for me (although I use it regularly). >>> Note that the script will also run all the ctests, which takes a long >>> time (I can disable this for you if you want though). Thus, if you do >>> try this, you might want to leave it overnight. >>> >>> I'd be happy to add support into the script of building Qt from source >>> if that would help. >>> >>> I've been using 14.04 since it came out. I don't know if there's >>> anything that requires it, but let me know if you have problems and >>> I'll take a look. > > I've updated my Ubuntu (running in a virtual machine) to 14.04 - but this > didn't solve my problem. With the Qt4 from Ubuntu it looks ok, though. > > I cannot use your scripts to test my changes - they're not in git yet. > But I've studied the scripts and think I don't need the full blown TeX > environment to see the rendering of LyX file content on screen. > > I cannot find a precompiled Qt5 for Ubuntu 14.04 - where should I look? > > Stephan -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgpKaosTuffZ2.pgp Description: PGP signature
Re: [PATCH] LyX HiDPI support in OS X with Qt 5
Let me chime in here as a non-lyx-programmer, but lyx user on a mac. I am sure there is a lot of interest among mac users for this patch. I also understand that it is not yet in a usable state, but when it is, would it be possible to make an unofficial dmg for mac users, so that this can be tested widely? As I understand, not many active developers of lyx are mac users, so a dmg would enable a much wider audience to test this. If it is only available as source, I don't thnik many mac users would compile it, unless it is put on homebrew... Cheers, and I am really looking forward to lyx on retina, Rainer Scott Kostyshak writes: > On Mon, Oct 13, 2014 at 7:38 AM, Stephan Witt wrote: > >> I'm trying to verify my changes on Linux. > > Thank you! > >> What are others doing to build LyX with Qt5 on Linux? > > You can see my build script here: > > https://github.com/scottkosty/lyx-tester/blob/master/lyxbuild > > If you want, you can have a completely automatic installation of > dependencies and building of LyX starting from a fresh Ubuntu > installation with one command: > https://github.com/scottkosty/lyx-tester > I only recommend that on a virtual box though. It has not been tested > except for me (although I use it regularly). > Note that the script will also run all the ctests, which takes a long > time (I can disable this for you if you want though). Thus, if you do > try this, you might want to leave it overnight. > > I'd be happy to add support into the script of building Qt from source > if that would help. > > I've been using 14.04 since it came out. I don't know if there's > anything that requires it, but let me know if you have problems and > I'll take a look. > > Best, > > Scott > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgpbjz_r8Fft6.pgp Description: PGP signature
Re: Backtrace from Mystery Crash
Just thinking - the sizes of the binaries with and without symbols seem to be the same. Wouldn't it be an option to always build as an unstripped binary, so that backtraces could easily be created, and possibly even automatically (after approval by the user, obviously) be mailed after a crash? Rainer Stephan Witt writes: > Hi John, > > I've put the package with the unstripped LyX binary here: > > https://dl.dropboxusercontent.com/u/27842660/LyX-2.1.0-unstripped%2Bqt4-cocoa.dmg.sig > https://dl.dropboxusercontent.com/u/27842660/LyX-2.1.0-unstripped%2Bqt4-cocoa.dmg > > It's made from the same tarball as the official 2.1.0 LyX I've made in April > 2014. > > Stephan > > Am 22.06.2014 um 16:48 schrieb jken...@ssc.wisc.edu: > >> Pavel: >> >> Yes, I'm happy to cooperate on this in any way I can (I use LyX every >> day, and I owe you guys big). But this crash is rare, so it might be a >> while before it happens again. >> >> John >> >>> John Kennan wrote: >>>> Yes, please attach your crash report here, if possible. >>>> >>>> http://www.lyx.org/trac/ticket/9049 >>>> >>>> If you don't have an account and don't want to create one >>>> you can sent it to the list, of course. >>> >>> We need backtrace with debug symbol on, this is not much helpful. >>> John, if you >>> are willing to cooperate on this bug Stephan might be able to produce >>> binary >>> with debug symbols from the current 2.1.x branch for you? >>> >>> Pavel >>> >> >> > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpI3tJSWAiJR.pgp Description: PGP signature
Re: Python Graphics in LyX [was: Python bindings]
"Alex Vergara Gil" writes: > Dear Lyxers! > > Studying a little of python and LyX I have reached to this feature > that makes LyX show and process python graphics. Thanks to Rainer M > Krug for the hints. I share this contribution for LyX under LGPL > license, so everyone benefits from it. Good luck and happy lyxing! > > Alex Vergara Gil > MSc Nuclear Physics > SSDL, CPHR, Havana Cuba > > PS: If Rainer agree, pass him from acknowledgements to author list, please. That looks beautiful. AS I have no idea how python works, co-author would probably better. Thanks, Rainer > > > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpjlZVv0m2yJ.pgp Description: PGP signature
Cross-posting on devel and
Hi There is recently a lot of cross-posting happening on lyx-devel and lyx-users which I think is a bit irritating and makes following discussions difficult (luckily, and this includes myself, most responders to cross-posted threads ignore that one should not cross-post and discussions are complete on both lists...). Nevertheless, I would like to know what the policy about cross-posting is. If cross-posting is OK, the merging of the two mailing lists should be considered, which might be a good idea in a relatively low traffic mailing list? The other option would be to discourage cross-posting, possibly even blocking mails to lyx-devel which are also posted to lyx-users? I am not a list administrator and I don't want to start a big discussion, so if nobody else objects, the status quo can be kept, Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgp6RUxCE4ugM.pgp Description: PGP signature
Re: [Feature Request] python binding
"Alex Vergara Gil" writes: > From: "Richard Heck" > Sent: Thursday, May 29, 2014 5:05 PM >>> I might be *completely* off, but couldn't you achieve exactly this via >>> defining converters? I have for example a converter defined, which >>> "converts" plantuml source fields into uml graphs, i.e. it defines the >>> call to compile them and return the graphs which are then inserted in >>> the document? >> >> Yes, that's more or less what I was suggesting. >> >> rh >> > I just add comments inline > Let's see if I understand: -1. You define a *file type* in LyX under Preferences > File Handling > File Formats for the file type .pygr in which "Vector graphics format" is ticked! 0. You define a converter under Preferences > File Handling > Converters which calls a script which executed files with the extension .pygr and generates, as you suggest below, an svg. > 1. I wrote a python script that produces the graphic I want Exactly - and you give it a specific extension .pygr for "python script which generates a graphic" which you defined above. > 2. I insert it in LyX somehow I don't know, perhaps defining a > converter from .py to svg, but this needs to be inside a module or > every python script in LyX will try to be converted into a svg!! So a > module is also needed Use insert graphic and select *your .pygr* file as graphic - and Lyx will do the rest of the conversion - i.e. use your converter to convert the .pygr to an svg and other existing converters to generate the png for the preview and the pdf / eps / ... for the final copmpilation of the document. > 3. LyX is the one who knows the correct size of the graphic so in > principle if I produce a svg should be enough but in this way I need > to produce a new svg every time the data change Correct - if the input data changes, you have to generate the graph again manually, or, if the "Converter file cache" is disabled, you just have to close the document and open it again. Hope this helps, Rainer > > Take this simple script as example > > import numpy as np > from numpy.random import randn > import matplotlib as mpl > import matplotlib.pyplot as plt > np.random.seed(9221999) > data = randn(75) > plt.hist(data) > > which produce a graphic like this in spyder > > > > So basically I save this graphic to a svg and then I load it into LyX, > but why not letting LyX doing this automatically if it already handles > with python?? This is my question. > > Regards > > Alex -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgp4Tu7FsXx7J.pgp Description: PGP signature
Re: [Feature Request] python binding
"Alex Vergara Gil" writes: > From: Richard Heck > Sent: Thursday, May 29, 2014 3:26 PM > > > On 05/29/2014 03:36 PM, Alex Vergara Gil wrote: > > Hello Lyxers > > I wonder why LyX is not available to process little pieces of > python code within its own framework, like ipython notebook for > instance?? > > > This feature allows us to have beautiful graphics such the one > produced by matplotlib package. I know there already exists a > similar binding for R through knitr module, so why not a binding > for python too?? > > Is there a way, like modules or whatever, to achieve the same > functionality or at least some basic functionality of ipython notebook > within LyX?? Can you be more precise about what you want to do? I've > never heard of ipython notebook. sudo aptitude install > ipython-notebook ipython notebook > > and there you can write even thesis in a web environment with python > commands being executed inlined, exporting to pdf and latex too, it is > a wonder of our times, so why not letting LyX do this miracle too?? > > Sweave works by our having an output format (sweave) for such > documents and then our declaring Rscript as a sweave --> LaTeX > converter, so PDF export (say) goes via Rscript and > pdflatex. There's a special script in lib/scripts/ that "sets up > some things for LyX" first, or so it claims. It would be reasonably > easy to do the same sort of thing for Python, if you wanted to do > so. You'd just need to set up an appropriate format and then declare > an appropriate script as a whatever -> latex converter. Then LyX > will run the script and do as you wish with the embedded python > code. > > Of course, as we've discussed on the list with respect to R, there are > large security issues here, too. > > Richard you obviously miss the point here, or I was not very clear! > it is not a different format, is a facility to have python scripts > running within LyX framework, you have to see ipython notebook to > understand what I mean, you will be surprised!! Basically to build > graphs, for instance (and only a piece of what can be done), you add > the (let's call it) "knitpy" module and then place a knitpy insert, > write some python code that produces a matplotlib graphic and then > when lyx compiles the document, instead of the code it is shown the > graph, it also can be done in the lyx editing window, but thats a more > dificult request. I might be *completely* off, but couldn't you achieve exactly this via defining converters? I have for example a converter defined, which "converts" plantuml source fields into uml graphs, i.e. it defines the call to compile them and return the graphs which are then inserted in the document? I have never used python, but I guess a similar approach should be possible here as well? Cheers, Rainer > > Regards > Alex -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpK0dzVm8JCx.pgp Description: PGP signature
Re: In TeX Live 2014, 3 example files will not export with LuaTeX/XeTeX
Cyrille Artho writes: > Liviu Andronic wrote: >> On Thu, May 22, 2014 at 10:12 AM, Jean-Marc Lasgouttes >> wrote: >>> 22/05/2014 08:09, Cyrille Artho: >>> >>>> Hi Scott, Thanks for your work in keeping the packages working. I'm >>>> still using foils (foiltex) so I'm very happy if it can be kept >>>> working for a long time. In fact, I was not aware that it is no >>>> longer maintained. That's too bad because I think I'm not the only >>>> one who still uses it. >>>> >>>> In my personal opinion, beamer uses too many boxes and does not look >>>> good if you use a lot of figures/images on the slides. Beamer slides >>>> may look better for text-only slides but those slides are boring to >>>> begin with ;-) >>> >>> >>> Yes, I depend on foils to. I tried beamer for my last presentation >>> (because I needed its slide animation features), but I really did not >>> like it. Too much bling for my taste. >>> >> I also have issues with all the bling that comes with Beamer by >> default, but with some few Beamer config tweaks all the bling can be >> toned down significantly. This is why I came up with a series of >> "simple" Beamer examples on the wiki: >> http://wiki.lyx.org/Examples/Beamer I just wanted to take a look at them, and all produce an error when opening from LyX (LyX Version 2.1.0 (13 Apr 2014)) on a Mac. , | /var/folders/50/wcr5bjwn75q595n6x82gxj28gn/T/lyx_tmpdir.twUHvMRS5559/Buffer_convertLyXFormatXX.lyx.kSameUIi5559 | ended unexpectedly, which means that it is probably corrupted. ` I though that the conversion by lyx2lyx is the problem, but that one works without problems. I attach the converted file (from [1]). Ironically, all non-simple beamer presentations open without error... conspiracy? :-) Cheers, Rainer new.lyx Description: Converted from beamer-simple.lyx >> >> Most changes are obtained very easily via simple Beamer calls in the >> Preamble. >> >> Liviu >> >> >>> OTOH, I reckon that foilTeX slides can be a bit ugly, and I'd welcome >>> another option. >>> >>> JMarc >>> > Hi Liviu, > Thanks for the links. IMHO even the "simple" style is rather heavyweight > for the boxes (with shadows etc.). I think the trend is now towards > cleaner, simpler layouts with no 3 D effects, and only as few > lines/boxes/frames/background colors as absolutely needed. > In that sense, what was done by necessity 15 years ago when doing slides in > LyX/TeX is now again in fashion ;-) > > Why FoilTeX works for me (sorry if this is getting off-topic): > > For my own slides, I change the bullet symbol and title color in FoilTeX > but otherwise use it without changes. Whenever possible, I avoid bullet > lists in the first place but of course I don't always have enough time to > get rid of enumerations. I never use "striptease slides" as the audience > tends to squint, trying to read the grey text on white, while not listening > to the speaker. IMHO if you use a "striptease slide", then you have failed > in the design and should create 2 - 3 separate (but incremental) slides > instead. Note that these may repeat a figure (with modifications) but > should not repeat the entire text as you'd otherwise again end up with a > wall of text. > > In short, beamer can make a wall of text look relatively pretty, and > this may work for a couple of minutes, but after that one realizes > again that walls of text are not suitable for presentations. Without > that, the most compelling features of beamer are not needed anymore. Footnotes: [1] http://wiki.lyx.org/uploads/Examples/Beamer/Liv/beamer-simple.lyx -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpwkpIzHZ0Js.pgp Description: PGP signature
Re: Feature: open pdf from right click on citation inset ?
Jean-Marc Lasgouttes writes: > 07/05/2014 09:41, Rainer M Krug: >>> I would like to be able to right click on a citation and be able to >>> click on "open pdf". The filenames of the papers I cite are all stored >>> with the author field of the BibTeX (followed by the extension >>> ".pdf"). Thus, I would just need to input the folder location into a >>> LyX document setting, and the feature would work. >> >> Interesting idea - and useful. But I would see it as a two step process: >> >> 1) right click - see bibtex entry >> 2) click on "file" field in the bibtex entry to see the pdf. In the same >> way, on could open URL to see the paper online. > > This seems more complicated for no real reason. You basically have the > information when hovering. Ups - must have missed this - sorry. > However, having a new menu entry "see > document" when there is a "pdf" or "postscript" or "url" entry (and > the ps or pdf file actually exists) would be neat. Yes - that would be neat - selecting which one could be useful, as they could contain different versions or documents (article, supplements, ...). > > When trying this out, I have a weird situation. I include a Bibtex > inset, pick bilbiography style "plain"; when I insert a Cite inset, > the only form that I can pick is one that shows the whole citation > like "Smith & Wesson (2002) In the Head: How to Get it Right Every > time, Springer" > > How come I cannot have a plain [1]? > > JMarc > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgp3TGTk2z_ke.pgp Description: PGP signature
Re: Feature: open pdf from right click on citation inset ?
Scott Kostyshak writes: > My first guess is that not many others would find this idea useful, > but I figured it's worth an email to see if I'm wrong. It is. > > I would like to be able to right click on a citation and be able to > click on "open pdf". The filenames of the papers I cite are all stored > with the author field of the BibTeX (followed by the extension > ".pdf"). Thus, I would just need to input the folder location into a > LyX document setting, and the feature would work. Interesting idea - and useful. But I would see it as a two step process: 1) right click - see bibtex entry 2) click on "file" field in the bibtex entry to see the pdf. In the same way, on could open URL to see the paper online. > > I'm guessing this feature might not make sense to be in LyX. I'm > expecting a response of "use JabRef" or another bibliography manager > that does that for me. I think this is not a "managing bibtex files" issue for Jabref et al. and could definitely has its place in LyX. +1 Rainer > > Any thoughts? > > Scott -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpSC0jwlKd7V.pgp Description: PGP signature
Re: Feature request
Scott Kostyshak writes: > On Thu, Apr 24, 2014 at 1:29 PM, Pavel Sanda wrote: >> Scott Kostyshak wrote: >>> Another problem is that some mailing lists require/encourage "quote >>> prior messages in entirety" (e.g. >> >> It makes any longer exchange unreadable. > > Agreed. > >> When involved in the exchange I usually care to strip it no matter what the >> other party does, but anyway it's not nice to let other people do your >> work... > > My point is that I think many do it out of ignorance, not laziness. At > least that was the case for me. I wish someone had told me sooner. In > the end it is my fault for not having remembered the list netiquette. Gmail has folding, Thunderbird has folding, GNUS has folding, and I assume most email clients have folding / hiding of quotes. As stated, some mailing lists wish to have the whole thread, to make reading a reply separately possible. Snipping of sections I do not reply to is OK, but selectively snipping out of sections I reply to make it possible to change the original meaning. So I think no snipping is not a major problem. Rainer > > Scott -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgp5RWA1JYiz0.pgp Description: PGP signature
Re: GSoC: Overhauling LyX's converter scheme
Jean-Marc Lasgouttes writes: > Le 11/03/2014 10:10, Roy Xia a écrit : >> Hi everyone, > > Hello, > >> I suppose my first question to you all is whether there are >> any alternative suggestions or additional goals out there for >> overhauling the converter scheme. > > To be frank I am not sure yet. We have some bugs in the current code, > like: a sweave document[*] (that outputs Tnw, and should follow a > Rnw->latex step) cannot use the platex (japanese) converter. platex > (or rather japanese) may need to be a modifier. > > [*] see the OutputFormat layout tag, that allows to preprocess latex files. > >> I also suspect that the >> path-finding algorithm will be further complicated by the presence of >> multiple flags; for example, I have noticed that pdf7 (PDF cropped) is >> not labeled as a vector graphics format whereas other pdf variants are, >> so if the pdf extension is to be consolidated I suspect that vector >> graphics format will also have to become a qualifier of some sort. > > I think that many of our flags will become modifiers. > >> In >> that sense, there may need to be some judgement on which converter chain >> to use if, for example, the search only results in two valid paths, one >> with qualifier A but not B, and another with qualifier B but not A. All >> said and done though I'm not an expert on the converters, so perhaps >> someone could shed some light on other considerations or critique my >> analysis of the task at hand. > > I suspect indeed that there will be several possible paths. We need > some criterion to find the better path. Criterion should be: 1) resulting quality 2) resulting size 3) length of conversion path (although I am not sure this is really that relevant) > >> As for dealing with the latex flavors, within the context of the >> converter it seems they aren't used for much aside from generating log >> and aux files--in fact, unless I missed something, > > It is used to set the OutputParams::flavor vluae and they change the > content of the LaTeX file. > >> My gut instinct says >> to just have a general "latex" flag set for each of these formats and >> automatically determine the proper program to call from there without >> knowing what specific type of latex it is, but since I'm not that >> experienced with latex or any of its flavors I'm not sure if that's the >> right approach. > > I would say that at first you decide to output "latex". If your final > format is pdf:pdflatex, then all the converter chain (and all the > formats in the list) inherits the "pdflatex" flag and therefore you > know that your first format has to be "latex:pdflatex". > >> Finally after all of those changes are in place there would probably >> need to be some UI changes to reflect the modified converter scheme, but >> I think that's more of an afterthought. > > Well our current converter setting UI is a mess so if there is enough > time, they woll deserve more than an afterthought. > > Finally, we may need to add some pref2pref python code to update the > users preferences. > >> Thanks for reading all of that and I appreciate any advice you have to >> spare. > > I think your thoughts are on the right track :) > > JMarc > > -- Rainer M. Krug email: RMKruggmailcom pgp6mW84RUkrb.pgp Description: PGP signature
Re: GSoC: Overhauling LyX's converter scheme
Jean-Marc Lasgouttes writes: > Le 11/03/14 10:43, Rainer M Krug a écrit : >> Just an observation from somebody not involved: >> >> The conversion route should be taking quality loss in consideration, >> i.e. a conversion path which only involves lossless conversions, even if >> it is longer, should be preferred. > > We already have a "vector" flag that serves this purpose, but we could > maybe improve on that. The vector is fine for - well - vector formats, but there should be an equivalent for bitmap formats, which can be lossless (tiff or png) or lossy (jpeg) and there could be different qualities (jpeg). It would be nice, if one could define a "draft conversion route" which then generates smaller, less resolution files for inclusion - but this might not be directly related. Rainer > > JMarc > -- Rainer M. Krug email: RMKruggmailcom pgpdjBVoQFKFj.pgp Description: PGP signature
Re: GSoC: Overhauling LyX's converter scheme
Roy Xia writes: > Hi everyone, > > So I've been studying the converter scheme in pursuit of the aforementioned > project suggestion. I've been mostly focusing on the particular changes > mentioned in the explanation on the wiki page; that is, to consolidate > output formats under one extension type but use qualifiers to distinguish > output format variants from one another, and to also refactor the converter > code to handle latex flavors more elegantly. I suppose my first question to > you all is whether there are any alternative suggestions or additional > goals out there for overhauling the converter scheme. > > I've also been studying the source code, gathering ideas on how the > overhaul might be implemented. As far as consolidating "variant" output > formats, I suspect that for the most part the actual conversion code will > remain the same, but a.) functionality for parsing and recognizing > qualifiers will need to be added, and b.) the path-finding algorithm for > finding the shortest chain will probably need to be somewhat modified to > first search for output formats with the desired qualifier and then search > for the generalized output format. I also suspect that the path-finding > algorithm will be further complicated by the presence of multiple flags; Just an observation from somebody not involved: The conversion route should be taking quality loss in consideration, i.e. a conversion path which only involves lossless conversions, even if it is longer, should be preferred. Cheers, Rainer > for example, I have noticed that pdf7 (PDF cropped) is not labeled as a > vector graphics format whereas other pdf variants are, so if the pdf > extension is to be consolidated I suspect that vector graphics format will > also have to become a qualifier of some sort. In that sense, there may need > to be some judgement on which converter chain to use if, for example, the > search only results in two valid paths, one with qualifier A but not B, and > another with qualifier B but not A. All said and done though I'm not an > expert on the converters, so perhaps someone could shed some light on other > considerations or critique my analysis of the task at hand. > > As for dealing with the latex flavors, within the context of the converter > it seems they aren't used for much aside from generating log and aux > files--in fact, unless I missed something, the different flavors only > differ from one another by which program they use to generate those files, > and the current code seems to determine that program solely from the > command associated with the converter anyway. My gut instinct says to just > have a general "latex" flag set for each of these formats and automatically > determine the proper program to call from there without knowing what > specific type of latex it is, but since I'm not that experienced with latex > or any of its flavors I'm not sure if that's the right approach. Again > perhaps someone could shed more light on this subject for me, or make sure > my thinking isn't totally off track. > > Finally after all of those changes are in place there would probably need > to be some UI changes to reflect the modified converter scheme, but I think > that's more of an afterthought. > > Thanks for reading all of that and I appreciate any advice you have to > spare. > > Roy Xia -- Rainer M. Krug email: RMKruggmailcom pgpFrhbB8ZI5P.pgp Description: PGP signature
Re: Update on discussions of LyX<-->Word export and round trip
> examples: LatexML >>>> >>>> b. Run Latex and process the resulting Pdf or DVI file into XML >>>> examples: tex4ht >>>> >>>> c. Modify an existing Tex engine to target XML instead of pdf (or dvi) >>>> examples: XML from Context input in LuaTeX >>>> >>>> All three approaches are ambitious and have different shortcomings. >>>> >>>> (a) (Mimicking Latex) has the obvious problem that even once the basic >>>> LaTeX functionality is recovered, the LaTeX packages have to be >>>> basically recreated for the new engine. This is what happens in >>>> LaTeXML, where you have to write "bindings" fr every package you need >>>> to support. At the moment, many packages are not supported, including >>>> biblatex, and from the little I have seen on their mailing list adding >>>> such support is not trivial. >>>> On the plus side, since XML is the target, all the formatting-only >>>> machinery of TeX can be ignored (well, in theory. Real world is messy) >>>> >>>> b. This approach has the advantage of bringing in support for all >>>> LaTeX packages for free. However, parsing a DVI file with the goal of >>>> producing XML is not trivial given the completely different design >>>> goals of DVI/vs/XMl >>>> >>>> c. Finally, modifying an existing TeX engine (e.g. LuaTeX) may be the >>>> cleaner approach---at the price of much increased complexity. >>>> >>>> 3. Should LyX<-->Word conversion be direct or use an intermediary >>>> format (e.g. pandoc | mmd | etc.)? >>>> >>>> This question applies mostly to the roundtrip project. The consensus >>>> seems to be that it would be better to avoid yet another format and go >>>> for direct conversion. On the minus side, such an approach would make >>>> it impossible (well, more difficult) to switch back-ends for the round >>>> trip, if so desired (see Rainer's points) >>> >>> Unless one defines a clear software interface, which can be used by >>> other converters. Effectively, this could mean to extend the LyX server >>> to provide the information needed by the converter. So the parsing would >>> be doing in LyX (advantage: no worries about different .lyx formats) and >>> the conversion into docx in the external converter. >> >> Right. Even though I am not sure I fully understand Rob's suggestion >> about using the server yet. >> >> >> -- >> __ >> Stefano Franchi >> Associate Research Professor >> Department of Hispanic Studies Ph: +1 (979) 845-2125 >> Texas A&M University Fax: +1 (979) 845-6421 >> College Station, Texas, USA >> >> stef...@tamu.edu >> http://stefano.cleinias.org -- Rainer M. Krug email: RMKruggmailcom pgpmUcwKgmRf_.pgp Description: PGP signature
Re: Update on discussions of LyX<-->Word export and round trip
stefano franchi writes: > On Mon, Mar 3, 2014 at 3:17 AM, Rainer M Krug wrote: >> stefano franchi writes: >> >>> Dear Lyx devels, >> >> Hi Stefano, >> >> thanks for a good summary of the discussion - I think you have >> identified the main points. I have some comments below. >> >>> >>> given the intense discussion we have had in the last few days on this >>> possible project, I thought I would briefly sum up some of the early >>> conclusions (also because some items were discussed in private >>> emails). >>> (BTW: In the following I say "Word" for the sake of brevity. I >>> actually mean Word XML | Libreoffice ODT) >>> >>> 1. One project or two? >>> >>> Is a LyX-->Word export a subset of the LyX<-->Word roundtrip? >>> >>> A. If the final ouput is Word, the conversion to Word is a subset of >>> the roundtrip *if and only if* the XML output preserve Lyx-only >>> (non-LaTeX) information (e.g. tracked-changes, LyX-notes, etc). >> >> This point needs to be clarified: If one needs a semantic export, this >> is true, as all semantic information needs to be maintained in the >> round-trip as well as in the export. But not if the export should *look >> like* the latex export. The limit in these discussions is semantics, and >> not as much formatting (exceptions do apply, e.g. italics or bold of >> words, which is important in articles which contain species names which >> have to be in italics). >> > > It should not. That is: a word-export conversion should *not* aim at > preserving formatting. It should preserve the same (often > formatting-encoded) semantic information of the round-trip converter. > The only difference is that LyX has only pointers for some of these > info (e.g. bibtes keys) and not the information itself. This is the > major problem. > (Additionally, some semantic LyX-provide semantic information could be > shed by the exporter, such as tracked-changes and so on. But this is a > minor problem). OK - then I agree completely with you. > > >> Additionally: if it is a subset - perfect - but as in (B), the >> round-trip does not have to include everything, as there could be a >> semantic exporter. >> >>> >>> B. If the final output is pdf, then it is not. It is not necessary to >>> actually process the info in the .tex file with Latex (e.g >>> bibliography,, and more). All we need to do is to make sure that the >>> info that Latex will eventually need are preserved through the >>> roundtrip. So, for a citation, we only need to make sure that when we >>> go to Word we produce something like (made up XML): >>> >>>citet >>> >>> myBibkey >>> >>> >>> >>> and when we come back we reconstruct the proper LyX bib inset from >>> those info. It will then be up to Latex to produce the actual citation >>> and the corresponding reference. >> >> Agreed. >> >>> >>> So scenario 2 is actually simpler, because we do not have a dependency >>> on LaTeX at all. >>> At the same time, scenario 1 is more important for those people who >>> are likely to interact with Word users (see Juergen's comments, which >>> I subscribe to). >> >> I would say to design the round-trip-export so that it can easily be >> extended to become a fully fledged semantic exporter. >> >>> >>> In general, then, we have overlapping projects with substantial >>> differences sets: >>> A - The LyX-only information that needs to be somehow encoded in the XML >>> file >>> B - The Latex-produced-only information that is missing from LyX >>> >>> Preserving LyX-only information in a XML file (A) strikes me as being >>> substantially easier than producing the LyX-missing information (B) >>> for the Word file. The latter requires TeX runs, the former does not. >> >> I assume you are here referring to the last A and B, as if I understand >> correctly, the first definition of A and B is the opposite? > > Yes, Sorry, I switched them up. But the following refers correctly to > the A and B options just mentioned. OK. > >> >> >>> >>> 2. How to produce a Word output, that is, how to solve problem B above? >>> Since TeX is basically required to process a Lyx-produced tex file, >>> the following approaches are available (there may be more than three, >>> but these have kn
Re: Update on discussions of LyX<-->Word export and round trip
on be direct or use an intermediary > format (e.g. pandoc | mmd | etc.)? > > This question applies mostly to the roundtrip project. The consensus > seems to be that it would be better to avoid yet another format and go > for direct conversion. On the minus side, such an approach would make > it impossible (well, more difficult) to switch back-ends for the round > trip, if so desired (see Rainer's points) Unless one defines a clear software interface, which can be used by other converters. Effectively, this could mean to extend the LyX server to provide the information needed by the converter. So the parsing would be doing in LyX (advantage: no worries about different .lyx formats) and the conversion into docx in the external converter. > > > > These seem to me to be the most important issues we face. I maybe > forgetting some important points. If so, please correct me. > Comments of any kind are welcome. One important point in the general design would be, to keep in mind that the round-trip converters do not depend heavily on the .lyx file format, which is likely (?) to change into xml in the medium future. Cheers, Rainer > > > Cheers, > > Stefano -- Rainer M. Krug email: RMKruggmailcom pgp3BLfAsFnwb.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
Richard Heck writes: > On 02/28/2014 02:43 AM, Jürgen Spitzmüller wrote: >> Am Donnerstag 27 Februar 2014, 12:29:36 schrieb stefano franchi: >>> - Bibliography support with suitable styles is a must. This feature >>> is as crucial to someone working in the Humanities, as math support >>> is for >>> someone working in the sciences. With the difference that scientists can >>> often avoid conversion to Word, while Humanists just can't. >> From my point of view (as someone being in the Humanities), this is >> almost all that matters and the criterion that makes LyX -> Docx/ODT >> conversion useful or completely useless for me. Everything else is >> just a plus. > > Here, I think it's especially helpful to distinguish "round trip" > conversion, which would be used during collaboration, from final > export for publication. I take it that in the former case we just need > to make sure not to lose bibliographic information. Only in the latter > case do we need to be able to use or mimic biblatex, or whatever, to > get the bibliographic information into some final form. Exactly - for round-trip, the format of the references is effectively irrelevant, as long as one can see which ones they are, whereas for export, the format is essential (not only for Humanities!). I would even go so far and say that the inclusion of a properly formatted bibliography in the round-trip would be causing more problems, as bibtex et al only help on the one way - but how to get a new reference back into LyX? So I would suggest to leave the citations in a basic format (e.g. #+#bibtexID1,bibtexID2#+#) as a comment in the docx, so that they can be seen. On the way back, #+#...#+# is then replaced by the citation command in LyX, and if inside the #+# is not a valid bibtex id, it is imported as a comment, which then can be interpreted by hand (could be a new reference). Rainer > > This Sort of thing has been frequently requested just for XHTML: Parse > the bbl file and use that to construct the bibliography. So perhaps > the problem should be solved there first. > > Richard > > -- Rainer M. Krug email: RMKruggmailcom pgpgzvY5CF8D3.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
Richard Heck writes: > On 02/28/2014 05:35 AM, Rainer M Krug wrote: >> Rob Oakes writes: >> >>> Dear Developers, >>> >>> I've been following this conversation from the shadows, but I had one >>> thought that they be relevant. >>> >>> I think everyone agrees that we want to avoid reimplementing the >>> internal logic of a LyX document. While thinking about what might be >>> the best way to implement a converter, it occurred to me that it might >>> be worthwhile to implement the converters as clients that are able to >>> use a LyX server session. >> This comes close to my thought about an API, but it would be even better >> in the sense of more versatile and easier usable by external tools. >> >> The server - client approach would be the optimal and most flexible approach. >> >>> For export, the server could load a document, provide data about inset >>> and paragraph contents, and the client could then convert the logical >>> representation to docx or odf. For import, the process might work in >>> reverse. The importer reads in the data from the document, translates >>> it to a logical format that could be consumed by the server, and the >>> server creates a new document. Document internals remain internal to >>> LyX, while the server-client communicate over a well-defined protocol >>> to interactively build the document. >> This would be the best approach, as the internals are hidden in LyX, and >> the external clients only ask the same questions to retrieve the content >> they need to do what they want to do. >> >> It would also open many more options, e.g. web based editing. > > The "building the document" part is already do-able. Every editing > action is an LFUN. Try it in the minibuffer: > layout-section Section 1 > break-paragraph > self-insert This is the contents. > footnote-insert > self-insert This is a footnote. > char-forward > self-insert That's all folks. > There's a bit of a problem here: There's no easy way to insert a space > after the footnote, from what I can see. > > I'm not sure I understand, conceptually, what the API would look like > going the other direction. The obvious way to "provide data about > inset and paragraph contents" would be to send the client a copy of > the LyX file. I mean, we have to serialize the data somehow, which is > something LyX even does internally. And the serialization looks just > like the LyX file. That allows us to reuse the code that reads the LyX > file to read serialized data produced internally. The main point would be, that this serialized content is independent of the .lyx file format used, i.e. that it stays the same (or at the least is backward compatible) through the conversion to any new file format (xml). The information given out of LyX could also be hierarchical, i.e. that for different requests, different kinds of content are provided an example would be that 1) a request for "text only" returns the text - without bibliography, formating of text (e,g, bold words), graphs, tables, headers as a paragraph, ... 2) a request for "paragraph formats" request returns the type of the paragraphs (Section, Subsection, List, enumeration, ...), which can then be merged into (1) 3) a third request for "character format" would return character formatting (e.g. bold) 4) a fourth request for "bibliograhy" returns where the citations are, the format and the .bib file 5) ... Consequently, the structure would be modular and new features could be easily added and implemented in the round-trip converter. Cheers Rainer > > Richard > > -- Rainer M. Krug email: RMKruggmailcom pgpkrMCK05G4g.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
Rob Oakes writes: > Dear Developers, > > I've been following this conversation from the shadows, but I had one > thought that they be relevant. > > I think everyone agrees that we want to avoid reimplementing the > internal logic of a LyX document. While thinking about what might be > the best way to implement a converter, it occurred to me that it might > be worthwhile to implement the converters as clients that are able to > use a LyX server session. This comes close to my thought about an API, but it would be even better in the sense of more versatile and easier usable by external tools. The server - client approach would be the optimal and most flexible approach. > > For export, the server could load a document, provide data about inset > and paragraph contents, and the client could then convert the logical > representation to docx or odf. For import, the process might work in > reverse. The importer reads in the data from the document, translates > it to a logical format that could be consumed by the server, and the > server creates a new document. Document internals remain internal to > LyX, while the server-client communicate over a well-defined protocol > to interactively build the document. This would be the best approach, as the internals are hidden in LyX, and the external clients only ask the same questions to retrieve the content they need to do what they want to do. It would also open many more options, e.g. web based editing. > > If I understand the LyX server pipe, it is already possible to retrieve > information about insets, citations, cross-references, and other > document components. Moreover, there are only a few properties for a > particular type of inset (ID, text, meta, etc.), which provides a > manageable way to handle output data. Might it even be possible to > export the data for a particular inset in a serialized key/value > format? This would allow for insets without a good output format to > main their data as DOCX/ODF metadata which could be faithfully > translated back during import. > > As I've followed the pandoc conversation, I've been concerned about the > introduction of another dependency. If the import/export tools can be > kept to LyX and some processing script, that seems easier to maintain > than a complex chain of tools and external dependencies which we don't > control. Pandoc in the round-trip is definitely a sub-optimal solution due to the reliance on another tool, and quite a few modules for pandoc would have to be written. It is a different topic to use pandoc for export, as in this case only one pandoc would be needed. Cheers, Rainer > > Just my 0.02. > > Cheers, > > Rob > -- Rainer M. Krug email: RMKruggmailcom pgp4vzHRb53UD.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
Richard Heck writes: > On 02/27/2014 03:44 AM, Prannoy Pilligundla wrote: >> >> I also had a look at pandoc and tex4ht but as they are converters >> from Latex,i feel we should only consider them as secondary options. > > I believe pandoc is pretty modular. One would only need to add LyX to > the list of formats that it handles and then, like magic, we could > convert the LyX format to anything else that pandoc handles. It seems > to me that this would be a very good approach. I really like pandoc, and it would be in my opinion, the perfect companion for one way export from LyX - as you said, this would be like magic. But it does not provide conversion from the target formats, only from: , | markdown, reStructuredText, textile, HTML, DocBook, LaTeX, MediaWiki | markup, OPML, or Haddock markup ` see [1] for details. Therefore I don't see it as useful for the round trip. > > The downside to any python-based approach, though, is that the LyX > format is a moving target. The script would need to be updated with > every syntax change. I assume that in LyX, there is an API which could be used to convert *independent* from the file format? I don't assume they are exposed outside LyX so that they can be accessed from e.g. python? Along this lines - I guess there are no news about the LyX xml format? Rainer > > Richard > > Footnotes: [1] http://johnmacfarlane.net/pandoc/ -- Rainer M. Krug email: RMKruggmailcom pgp7al2AcB8Lp.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
Prannoy Pilligundla writes: > I have been following the discussion going on in this thread and have been > exploring Lyx at the same time.I understood how to integrate python scripts > into the editor and all but i have a some queries regarding the round trip > conversion > > Since we have something like eLyxer which parses the Lyx format,can we > modify the eLyxer program and use this python-docx library( > https://github.com/python-openxml/python-docx) or anyother library which > helps in creating .docx files?In this way maybe we can also inject metadata > which MS Word ignores.Since we already have the .docx--->.lyx converter > written by Rob(http://blog.oak-tree.us/index.php/2012/03/08/word2lyx01-2) > we can modify it to read the metadata also. I have my reservations of sticking to close to the docx file format in the implementation, as my initial idea was that the conversion process is modular, and other backends can be plugged in easily, while re-using basic metadata extraction and format specification mechanisms. So effectively, the initial idea (from my side) to 1) read supported round-trip feature list from config file 1) extract metadata, i.e. features which are not supported by round-trip, into file 2) convert remaining round-trip-suitable data into new format 3) possibly merge metadata into file, or leave in sidecar file - file goes away - do something in other format (edits, ...) - file returns 4) extract metadata, i.e. features which are not supported by round-trip, from file / sidecar file 5) convert remaining round-trip-suitable data into lyx format 6) merge metadata back into lyx file So existing converters might be a starting point for (2) and (5), but they should be optimized for semantic conversion of the supported round-trip-features and not trying to convert formats. The basic reasoning is here, that only 1) the definition of supported features 2) converter definitions (2) and (3) and 3) how to merge metadata into second format (3) need to be changed to support other formats (e.g. markdown come to mind). Or am I aiming to high here? > I feel we should be able to do a > roundtrip conversion this way but i am not sure of the math part.I mean i > should read more how can we convert mathematical expressions from .lyx to > .docx. Can someone please brief me on what's the crucial information that > is absent in Lyx but produced by Latex? Information which is missing in the LyX document but generated by LaTeX is 1) bibliography information and format 2) Text in cross references and citation format 3) similar to (2) figure, table, ... caption labels 4) constructs in ERT blocks, like tikz graphs et al Out of the head, I can't think of anything else, at the moment > > I also had a look at pandoc and tex4ht but as they are converters from > Latex,i feel we should only consider them as secondary options. I thought about pandoc as well, but the problem is the back conversion, as it does not accept docx as input format. And I think a chain of converters (as used for pictures and graphs in LyX) introduces to many potential instabilities in such an important feature. > > I am new to the Lyx community so please forgive me if you find any of my > suggestions too lame because i may not have complete overview and insight > into things. No problem at all - go ahead with asking. Cheers, Rainer > Also it would be great if someone could provide me links to > understand the .lyx format.I wrote a simple .lyx file and opened it in a > text editor and found a lot of stuff,i think i should be able to understand > this properly if i want to parse a .lyx file and convert it to something > else > > Thanks and Regards > Prannoy Pilligundla > ᐧ -- Rainer M. Krug email: RMKruggmailcom pgpmkMmvfpG3P.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
William Adams writes: > On Feb 25, 2014, at 11:03 AM, stefano franchi wrote: > >> Is the list comprehensive enough? > > No love for index entries? Not from my side - sorry. Rainer > > William -- Rainer M. Krug email: RMKruggmailcom pgplFvC5aAhzZ.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
stefano franchi writes: > I am preparing a LyX document with all the features listed in our GSOC > 2014 page. I will transfer it to ODF with tex4ht, possibly fix it > manually, and then will circulate it on list for ODF/Docx tests. I think this is a brilliant idea - ths could then become the benchmark for the complete round-trip. > > Here is what I am including: > > sections, headers, ... > lists > emphasis, bold, ... > comments > track changes > tables and figures > footnotes > bibliographic references > math > cross-references > tracked changes > > It will have one section per item, do we can focus the tests on one > feature at a time, and perhaps split the document in mini-docs an have > a series of unit tests of sorts. > > > Question: > > 1. Is the list comprehensive enough? Too comprehensive? We should possibly prioritize some aspects which are more essential then others. There will very likely be some different views on e.g. math and footnotes, but I assume that there are some we can agree on. My list would be, in descending order of importance: 1) sections, headers, ... 2) lists 3) emphasis, bold, ... 4) comments 5) track changes 6) tables and figures 7) bibliographic references 8) tables 9) figures 10) math, footnotes & cross-references > > 2. For the Math: anyone having favorite equations / math constructs > that represent a sort of "baseline" case that would be desired and > other cases that would be the "optimum". I am thinking of the > complicated things I sometimes here you guys discussing on the list > and which I never use Not from my side - sorry. I prefer simple maths. Looking forward to the document, Rainer > > > S. > > > On Tue, Feb 25, 2014 at 8:58 AM, Richard Heck wrote: >> It looks to me as if ODT <--> docx is OK via Libre Office. And if it's >> editors of journals, etc, then one way is good enough, no? >> >> R >> >> On Feb 25, 2014 4:15 AM, "Rainer M Krug" wrote: >>> >>> Wilfried writes: >>> >>> > Rainer M Krug wrote: >>> > >>> >> Wilfried writes: >>> >> >>> >> > stefano franchi wrote: >>> >> > >>> >> >> On Sun, Feb 23, 2014 at 1:29 PM, Rainer M Krug >>> >> >> wrote: >>> >> >> > stefano franchi writes: >>> >> >> > >>> >> >> >>> >> >> >> 2. Whether to target Microsoft's Word XML format or the Open >>> >> >> >> Document >>> >> >> >> Format (similarly XML-based) >>> >> >> > >>> >> >> > I would strongly argue for the Microsoft Word XML, as each >>> >> >> > conversion >>> >> >> > creates problems and inconsistencies. This said, if the conversion >>> >> >> > from >>> >> >> > MS Word XML to ODF and back can be done without causing problems >>> >> >> > in the >>> >> >> > roundtrip (i.e. the round-trip would then be lyx - ODF XML - MS >>> >> >> > XML - >>> >> >> > ODF XML - lyx)I would argue for the more "open" format which can >>> >> >> > be used >>> >> >> > on more Operating systems. >>> >> >> > >>> >> >> >>> >> >> I have been told that, in its most recent versions, Microsoft Word >>> >> >> can >>> >> >> read ODF version >= 1.2 directly. That is, it can open, >>> >> >> edit, and save files in OpenOffice's native format. I have no means >>> >> >> of >>> >> >> checking this assertion, as I have no access to MS Word. >>> >> >> Could anyone with such access give it a try? >>> >> > >>> >> > In principle, this is true. >>> >> > However OO (I tested with Apache OO 4.01) cannot save in the latest >>> >> > Word >>> >> > format (.docx), and saveing as MS .xml results in complete loss of >>> >> > the >>> >> > equations. >>> >> >>> >> This is not true for Libre Office (4.1.2.3) on ac - I just tried, and a >>> >> small formula in LibreOffice, saved as .odt, then saved as .docx >>> >> (Microsoft Office 2007/2010 XML) resulted in a docx which could be >>> >> opened in Word 2011 and the equation was th
Re: GSOC 2014 -- next steps
stefano franchi writes: > Dear Lyx developers, > > as you know, we have been accepted into GSOC 2014. The next step is to > get ready to evaluate students' proposal, which will start coming in > about a week, with the usual flurry as we get close to the deadline > (March 21st). > > I would appreciate if all the developers who participated in GSOC last > year could register again as mentors on google-melange [1], *even if > you do not plan to be an active mentor* this year. Registration on > melange will give you access to the proposals and will let you assess > them. > > Notice that you may have to reregister with google-melange, as te app > seems to have deleted usernames from last year. Both Liviu and I had > to do so. Once you are properly logged in, go to the Dashboard and > click on "connect with organizations" requesting the role of mentor. > Liviu or I will have to approve your request, after which you will > recive a confirmation and you'll be ready to roll. Just to inform you, I have registered as a co-mentor for the roundtrip project. I will not be able to provide programming mentoring as I have no knowledge in the internals of LyX, but I would be very much interested to be involve=d in the discussion about the direction and outline of the roundtrip, as I was one of the initial authors ot=f the proposal. Cheers, Rainer > > Thanks! > > Stefano > > > [1] https://google-melange.appspot.com/gsoc/events/google/gsoc2014 -- Rainer M. Krug email: RMKruggmailcom pgptDs5d5BXe_.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
Wilfried writes: > Rainer M Krug wrote: > >> Wilfried writes: >> >> > stefano franchi wrote: >> > >> >> On Sun, Feb 23, 2014 at 1:29 PM, Rainer M Krug wrote: >> >> > stefano franchi writes: >> >> > >> >> >> >> >> 2. Whether to target Microsoft's Word XML format or the Open Document >> >> >> Format (similarly XML-based) >> >> > >> >> > I would strongly argue for the Microsoft Word XML, as each conversion >> >> > creates problems and inconsistencies. This said, if the conversion from >> >> > MS Word XML to ODF and back can be done without causing problems in the >> >> > roundtrip (i.e. the round-trip would then be lyx - ODF XML - MS XML - >> >> > ODF XML - lyx)I would argue for the more "open" format which can be used >> >> > on more Operating systems. >> >> > >> >> >> >> I have been told that, in its most recent versions, Microsoft Word can >> >> read ODF version >= 1.2 directly. That is, it can open, >> >> edit, and save files in OpenOffice's native format. I have no means of >> >> checking this assertion, as I have no access to MS Word. >> >> Could anyone with such access give it a try? >> > >> > In principle, this is true. >> > However OO (I tested with Apache OO 4.01) cannot save in the latest Word >> > format (.docx), and saveing as MS .xml results in complete loss of the >> > equations. >> >> This is not true for Libre Office (4.1.2.3) on ac - I just tried, and a >> small formula in LibreOffice, saved as .odt, then saved as .docx >> (Microsoft Office 2007/2010 XML) resulted in a docx which could be >> opened in Word 2011 and the equation was there. I=t could be edited and, >> when re-opened in LibreOffice, the edits were there. >> >> > Round trip is best if saving to Word 97/2000/2003 .doc >> > format. >> >> As far as I know, doc is a non documented binary format - so I would >> definitely not go there. >> >> > >> > Word supports 3 ways to write equations: >> > The oldest one is the EQ field function, which is easy to convert but >> > rarely used in practice. >> > The next is using the Equation Editor (standard for up to Word 2000) or >> > its mature brother MathType which both create MTEF objects. >> > The latest are Word 2007 and up equations (with a different object type >> > OMML). >> > And OpenOffice has its own equation editor which creates another object >> > type, which cannot be converted to any of Word's equation types, at >> > least not by Word nor by MathType (up to 6.7.a - current version is >> > 6.9). However, Mathtype can convert to and from MathML and LaTeX. >> > The newer Word equation object can only be converted to the older object >> > type by MathType (AFAIK). >> >> I can not comment on this. >> >> > >> > An OO document, containing an equation created in OO, saved as MS .doc >> > (Word 97/2000/2003) and opened in Word 2010 contains the equation but >> > this equation is not editable in Word - for editing this equation one >> > needs OpenOffice installed. At least after the round trip OO -> .doc -> >> > Word -> .doc -> OO the equation is still editable in OO. >> > And an equation created in Word is not editable in OO. Even worse, if >> > one uses the newer (Word 2007 and up) equation format (which is default >> > if one uses the .docx format), then saves as .doc, the newer equations >> > are irreversibly converted to pictures. >> > >> > Hope that makes the problems more clear. >> >> As I stated above, I could create a document =in Libre office, including >> equation, save it as docx, open it in Word 2011, edit the formula, save >> it, open the document in LibreOffice, edits were there, and I could >> continue editing there. May be differences between OpenOffice and >> LibreOffice? > > I comparedLibreOfficeandOpenOffice: > > Save as .doc yesyes > Equation saved asMTEF, editable OOmath, not editable > Roundtripno, stays MTEF remains OOMath > MTEF remains MTEF > > Save as .docxyes no > Equation saved asOMML, editable > Roundtripyes, back to OOMath > MTEF remains MTEF > > > A
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
stefano franchi writes: > On Mon, Feb 24, 2014 at 5:21 PM, Cyrille Artho wrote: >> I agree. A user who is interested in using LyX is also going to install >> LibreOffice (if it's not already installed). Furthermore, we can't expect >> student participants to pay hundreds of dollars just to be able to test the >> converter. >> >> >> Richard Heck wrote: >>> >>> On 02/24/2014 06:11 PM, stefano franchi wrote: >>>> >>>> On Mon, Feb 24, 2014 at 3:41 PM, Georg Baum >>>> wrote: >>>>> >>>>> Rainer M Krug wrote: >>>>> >>>>>> As far as I know, doc is a non documented binary format - so I would >>>>>> definitely not go there. >>>>> >>>>> AFAIK there are many details known about .doc, but this is a dead >>>>> format, >>>>> and any round trip that uses it will be obsolete rather sooner than >>>>> later. >>>>> >>>> >>>> I agree completely. Let's avoid dead formats and focus on the choice >>>> Word vs. ODF >>> >>> >>> I would have thought it was in the spirit of the project to focus on ODF. >>> Word reads and writes it, and anyone who's a Word-user can download and >>> use >>> Libre Office for free without much loss. >>> > > > I agree, in principle and on practical grounds too (see the > possibility to leverage tex4ht). However, it is true that the eventual > users of the Lyx-->Doc converter (and of the roundtrip tool) will > overwhelmingly be Word users, not LibreOffice users. Before we choose > to go down the ODF path I would very much like to test whether the > core features we are interested in---semantic marking, footnotes, > math, changes, notes and possibly frames---can survive the > ODF<-->Word round trip. > > Is anyone with Word willing to carry out the test? I can provide a > test document in ODF format. I can test it on a Mac. If you send me the document privately, I can 1) save it in LibreOffice 4.1.2.3 as .docx 2) open it in MS Word:Mac 2011 14.3.9 3) compare the documents 4) do a minor edit (if you have any specific edits I shoud do, please let me know) 5) save it again 6) open it in LibreOffice I will also create pdfs of each stage. We have to keep in mind, that it seems that at least MS Office 2011 on a Mac *can not* read and write .odt files. If somebody using a newer version of OS Office for Mac can confirm this? Cheers, Rainer > > > S. -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug pgpMtpyTThwim.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
Wilfried writes: > stefano franchi wrote: > >> On Sun, Feb 23, 2014 at 1:29 PM, Rainer M Krug wrote: >> > stefano franchi writes: >> > >> >> >> 2. Whether to target Microsoft's Word XML format or the Open Document >> >> Format (similarly XML-based) >> > >> > I would strongly argue for the Microsoft Word XML, as each conversion >> > creates problems and inconsistencies. This said, if the conversion from >> > MS Word XML to ODF and back can be done without causing problems in the >> > roundtrip (i.e. the round-trip would then be lyx - ODF XML - MS XML - >> > ODF XML - lyx)I would argue for the more "open" format which can be used >> > on more Operating systems. >> > >> >> I have been told that, in its most recent versions, Microsoft Word can >> read ODF version >= 1.2 directly. That is, it can open, >> edit, and save files in OpenOffice's native format. I have no means of >> checking this assertion, as I have no access to MS Word. >> Could anyone with such access give it a try? > > In principle, this is true. > However OO (I tested with Apache OO 4.01) cannot save in the latest Word > format (.docx), and saveing as MS .xml results in complete loss of the > equations. This is not true for Libre Office (4.1.2.3) on ac - I just tried, and a small formula in LibreOffice, saved as .odt, then saved as .docx (Microsoft Office 2007/2010 XML) resulted in a docx which could be opened in Word 2011 and the equation was there. I=t could be edited and, when re-opened in LibreOffice, the edits were there. > Round trip is best if saving to Word 97/2000/2003 .doc > format. As far as I know, doc is a non documented binary format - so I would definitely not go there. > > Word supports 3 ways to write equations: > The oldest one is the EQ field function, which is easy to convert but > rarely used in practice. > The next is using the Equation Editor (standard for up to Word 2000) or > its mature brother MathType which both create MTEF objects. > The latest are Word 2007 and up equations (with a different object type > OMML). > And OpenOffice has its own equation editor which creates another object > type, which cannot be converted to any of Word's equation types, at > least not by Word nor by MathType (up to 6.7.a - current version is > 6.9). However, Mathtype can convert to and from MathML and LaTeX. > The newer Word equation object can only be converted to the older object > type by MathType (AFAIK). I can not comment on this. > > An OO document, containing an equation created in OO, saved as MS .doc > (Word 97/2000/2003) and opened in Word 2010 contains the equation but > this equation is not editable in Word - for editing this equation one > needs OpenOffice installed. At least after the round trip OO -> .doc -> > Word -> .doc -> OO the equation is still editable in OO. > And an equation created in Word is not editable in OO. Even worse, if > one uses the newer (Word 2007 and up) equation format (which is default > if one uses the .docx format), then saves as .doc, the newer equations > are irreversibly converted to pictures. > > Hope that makes the problems more clear. As I stated above, I could create a document =in Libre office, including equation, save it as docx, open it in Word 2011, edit the formula, save it, open the document in LibreOffice, edits were there, and I could continue editing there. May be differences between OpenOffice and LibreOffice? Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug pgpD0M2w9iCZA.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
stefano franchi writes: > On Sun, Feb 23, 2014 at 1:29 PM, Rainer M Krug wrote: >> stefano franchi writes: >> > >>> 2. Whether to target Microsoft's Word XML format or the Open Document >>> Format (similarly XML-based) >> >> I would strongly argue for the Microsoft Word XML, as each conversion >> creates problems and inconsistencies. This said, if the conversion from >> MS Word XML to ODF and back can be done without causing problems in the >> roundtrip (i.e. the round-trip would then be lyx - ODF XML - MS XML - >> ODF XML - lyx)I would argue for the more "open" format which can be used >> on more Operating systems. >> > > I have been told that, in its most recent versions, Microsoft Word can > read ODF version >= 1.2 directly. That is, it can open, > edit, and save files in OpenOffice's native format. I have no means of > checking this assertion, as I have no access to MS Word. I remember trying this with an older version of word (I think it was 2010) by using the additional plugin by Microsoft to read odt, but quite a few formatings were lost and there was an issue with repairing the file. I just checked Office Mac 2011, and it can't open .odt format. But The windows version can, apparently: http://office.microsoft.com/en-us/word-help/use-word-to-open-or-save-a-document-in-the-opendocument-text-odt-format-HA010355766.aspx As a side note: MS states on the above mentioned page according to collaboration: , | When you collaborate on a document shared between Word and another word | processing application, such as Google Docs or OpenOffice.org Writer, | think of writing (the words) and formatting (the look) as different | tasks. Complete as much of the writing as possible without applying | formatting to the text and save the formatting until the end. This | allows you to focus on the writing while minimizing the loss of | formatting as you switch between the OpenDocument Text format and Word | format. ` Cheers, Rainer > Could anyone with such access give it a try? > > S. -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug pgpFEcBhlWAQt.pgp Description: PGP signature
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
s this approach. The project is not actively developed now, due to the untimely death of its founder, but it is still available, and it actually works. tex4ht runs latex with a special style which inserts parsing commands into LaTeX's DVI output. A java program then parses the special DVI output and produces html or ODF output. This approach allows tex4ht to exploit Latex's own processing (including the processing of index and bibliographic information), at the cost of increased complexity. One possibility would be to follow tex4ht's approach, while simplifying as much as possible the kind of LaTeX information actively supported. One important drawback of this second strategy (LyX-->LaTeX-->Word|ODF) is that LyX's only information are lost when converting to LaTeX. The most important of those are tracked changes. Standard LaTex has no conception of tracked changes. There are LaTeX additional packages that manage changes (e.g. [7]), and we would have to convert LyX's changes into that format. This of course adds an additional dependency, unless the package functionalities are somehow replicated by us. 2. Whether to target Microsoft's Word XML format or the Open Document -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug pgp97EUI2H0Kl.pgp Description: PGP signature
Re: Requst: Improved use of maxima inside LyX
On 02/11/14, 13:06 , Rami Veiberman wrote: > Hello, > > I'm using maxima as a smart calculator while working on my documents > inside lyx and it is working quite well. I also use wxmaxima by itself > to make some calculations and symbolic math easily. > > I wish I could do both. I wonder if I can open maxima session using a > command at lyx which will evaluate all maxima indicated cells and help > me create my smart document. > My final goal is to be able to create nice documents (which lyx does > just great) and be able to use some symbolic math and simple function > plots (which maxima does well) but today it is just not possible to > combine the two. > > for example, I want to define varibales at the start of the document. > something like > > var1:2 , var2:13 > > and then later to do > > ans:var1^2 + var2 > > today I'm unable to do so :( You are looking for something like knitr or sveawe for R (which are supported in LyX) for maxima - I don't think something like this exist. But at least for graphs, you could use R. Cheers, Rainer > > I am aware that wxmaxima can use latex text output but it lacks the nice > GUI of LyX which I'm very found of and it also lacks the support for > hebrew that LyX has. > > can we combine the two worlds into a better future? > > Rami -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On 02/10/14, 21:47 , stefano franchi wrote: > > > > On Mon, Feb 10, 2014 at 2:36 PM, Rainer M Krug <mailto:rai...@krugs.de>> wrote: > > I have the feeling, this discussion can be summed up in two lines: > > 1) we would like to have a round-trip (docx backend) > 2) but we need a sematic export (to docx) > > > Or perhaps: > 1) we would like to have a round-trip (docx backend) > 2) but we need a semantic export (to docx) > 3) so let's begin with (2) > 4) and hopefully will will halfway through to (1) Agreed - We can work on that. > > The important question is: > > - which design decisions in (2) could prevent a successful roundtrip? > How do we avoid those? Exactly - and also, which elements in LyX should be (initially) included in the semantic export and how they should be mapped. I won't be able to help in regards of any programming questions, as I know neither the inner workings of LyX nor of docx, but I would be more then interested in participating in these kind of discussions and support. Cheers, Rainer > > > S. > > > > -- > __ > Stefano Franchi > Associate Research Professor > Department of Hispanic Studies Ph: +1 (979) 845-2125 > Texas A&M University Fax: +1 (979) 845-6421 > College Station, Texas, USA > > stef...@tamu.edu <mailto:stef...@tamu.edu> > http://stefano.cleinias.org -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
I have the feeling, this discussion can be summed up in two lines: 1) we would like to have a round-trip (docx backend) 2) but we need a sematic export (to docx) Rainer On 02/10/14, 21:09 , Georg Baum wrote: > Rainer M Krug wrote: > >> On 02/09/14, 20:25 , Georg Baum wrote: >> >>> This is not possible. There are LyX features that simply do not appear in >>> the exported LaTeX, so they can't be imported (e.g. branches or notes). >>> It might be possible to support all LaTeX features, but the cost would be >>> extremely high, so there will always be LaTeX files which can't be >>> imported (usually the stuff found in .cls or .sty files). >> >> OK - in this regard you are right - haven't considered branches. But LyX >> notes could be exported as LaTeX comments starting with %%LyX-Note%%. >> >> Branches: isn't there conditional compiling in LaTeX? In this way >> branches could be kept and switched by activating these in the preamble? > > Yes. IIRC there was even a discussion about how to translate branches into > LaTeX if-statements some time ago, so branches are may not be the best > example. Anyway, there will always be features without direct LaTeX > representation, > >>>> So: yes, the round-trip framework could be used for a subset of features >>>> initially for LyX <-> LaTeX, which can then be extended over time - I >>>> guess this would be the easiest to start with, actually. >>> >>> This does not make sense IMHO. Why artificially restrict the roundtrip? >> >> Because, as you said above, some features in LyX can not be exported >> into LaTeX and the other way round? > > OK, if you meant these features I agree, then I probably misunderstood you > in the first place. > >> In addition, the round-trip would be >> needed to mainly edit content, and not that much formating - how a >> section header looks in word or in LyX is irrelevant, as long as it is >> recognised in the re-import / re-export for round-trip as a section >> header. In Contrast, when exporting (non-round trip) one wants a >> document as similar as possible to the LyX / LaTeX pdf (in most cases). > > This is a useful feature as well, but IMHO not restricted to roundtrip: Even > if you want to do a one-way export (e.g. because you know that somebody else > will continue to work on the document and it will never come back to you), a > switch similar to the "clean" option of writer2latex would be a good thing > to have. > >> You are right - LaTeX is a special case, as it is the default backend >> for LyX. So there are more strict requirements for the round-trip, and >> all improvements in the round-trip should be immediately in the LaTeX >> importer as well. But the story is different with other backends, e.g. >> docx, where, if you go to replicating the LaTeX view, you might end with >> "painted" documents which are not easily to be re-imported into LyX. But >> for round trip, the look is not that relevant, as long as the content >> and the structure can be re-imported. > > I believe this alls boils down to semantic export as Stefano called it vs. > "painted" export, and semantic export would be useful with roundtrip and > without. > > > Georg > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On 02/10/14, 21:09 , Georg Baum wrote: > Rainer M Krug wrote: > >> On 02/09/14, 20:25 , Georg Baum wrote: >> >>> This is not possible. There are LyX features that simply do not appear in >>> the exported LaTeX, so they can't be imported (e.g. branches or notes). >>> It might be possible to support all LaTeX features, but the cost would be >>> extremely high, so there will always be LaTeX files which can't be >>> imported (usually the stuff found in .cls or .sty files). >> >> OK - in this regard you are right - haven't considered branches. But LyX >> notes could be exported as LaTeX comments starting with %%LyX-Note%%. >> >> Branches: isn't there conditional compiling in LaTeX? In this way >> branches could be kept and switched by activating these in the preamble? > > Yes. IIRC there was even a discussion about how to translate branches into > LaTeX if-statements some time ago, so branches are may not be the best > example. Anyway, there will always be features without direct LaTeX > representation, > >>>> So: yes, the round-trip framework could be used for a subset of features >>>> initially for LyX <-> LaTeX, which can then be extended over time - I >>>> guess this would be the easiest to start with, actually. >>> >>> This does not make sense IMHO. Why artificially restrict the roundtrip? >> >> Because, as you said above, some features in LyX can not be exported >> into LaTeX and the other way round? > > OK, if you meant these features I agree, then I probably misunderstood you > in the first place. > >> In addition, the round-trip would be >> needed to mainly edit content, and not that much formating - how a >> section header looks in word or in LyX is irrelevant, as long as it is >> recognised in the re-import / re-export for round-trip as a section >> header. In Contrast, when exporting (non-round trip) one wants a >> document as similar as possible to the LyX / LaTeX pdf (in most cases). > > This is a useful feature as well, but IMHO not restricted to roundtrip: Even > if you want to do a one-way export (e.g. because you know that somebody else > will continue to work on the document and it will never come back to you), a > switch similar to the "clean" option of writer2latex would be a good thing > to have. I agree - there would be nothing stopping you to use the round-trip export for a semantic export, as you define it below. > >> You are right - LaTeX is a special case, as it is the default backend >> for LyX. So there are more strict requirements for the round-trip, and >> all improvements in the round-trip should be immediately in the LaTeX >> importer as well. But the story is different with other backends, e.g. >> docx, where, if you go to replicating the LaTeX view, you might end with >> "painted" documents which are not easily to be re-imported into LyX. But >> for round trip, the look is not that relevant, as long as the content >> and the structure can be re-imported. > > I believe this alls boils down to semantic export as Stefano called it vs. > "painted" export, and semantic export would be useful with roundtrip and > without. Nothing to add here - a semantic export would be really a very useful addition to LyX. > > > Georg > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On 02/10/14, 14:59 , stefano franchi wrote: > > > > On Mon, Feb 10, 2014 at 3:41 AM, Rainer M Krug <mailto:rai...@krugs.de>> wrote: > > > > On 02/09/14, 19:44 , Georg Baum wrote: > > Rainer M Krug wrote: > > > >> The idea would be that a round-trip framework is envisaged, which > >> provides the facilities to easily expand it from one export backend > >> (docx) to another (possibly odt? markdown?). > >> > >> IMPORTANT: this would NOT change ANYTHING in the existing export / > >> import features, as these are geared to export / import the > documents as > >> good as possible, with maintaining as many features as possible > in the > >> document. > >> > >> The round-trip would guarantee that: > >> > >> A document authored in LyX would result in a e.g. docx with a LIMITED > >> set of features, but that a re-import would result in the SAME .lyx > >> file. features and formats not supported by the backend should be > stored > >> in a metadata file. > >> > >> The important point here is *limited set of features*! > >> > >> In addition, the framework should be easily, possibly only by using > >> config files, able to be extended to other formats. > > > > I don't understand the difference between round trip and the existing > > export/import here. Why is it important? If the additional metadata is > > stored in a different file, it could simply be generated for the > standard > > export, and be used by the standard import (if it exists). > > > > The goal of the export/import is to support as many features as > possible. > > This is needed for round trip as well. The only difference I see > is the > > additional metadata file, so the roundtrip framework vs. export/import > > difference reduces to a switch whether the metadata file should be > generated > > (for export) or used (for import). Or did I understand anything wrong? > > The difference is that for round-trip, i.e. working together with > co-authors and getting comments back, a different set of features are > relevant. These are mainly concerned about content and not that much > formating. The import - export is concerned with both. In addition, a > round trip has to be symmetric, i.e. that exported features have to be > available in the re-importd as well - this is not the case in the export > and import. Lastly, round-trip is for editing, and export - import is > for editing and final consumption (reading). > > > > I actually disagree on this point: the most useful doc-export facility > for LyX would be equally focused on semantic content and not on > formatting. Only partial disagreement - In the case you describe below, the export to semantic, which is equal to the round-trip export, would be the end product. So let's call it a "semantic exporter" versus a "complete exporter" (as the one used export to for LaTeX). > In other words, it would be just half (or slightly less than > half) of the round-trip project. The rationale is simple: exporting to > doc(x) makes sense and is actually required when working with a third > party (typically, for Lyx's main audience, with a publisher) who will > then either provide final formatting directly with Word (the worst case) > or will use the doc(x) file as import into a real typesetting program > (InDesign, etc). In neither case formatting instructions are relevant. I > think it is a losing proposition to aim for the preservation of format > when exporting to Word---and in fact it is the reason why, in my > experience, *all* latex-to- word- (or to-odt) or lyx-to-word exporters > actually fail in practice. It is impossibly hard to provide the same pdf > look that (la)tex produces with Word. And the use cases in which this > conversion is required are exceedingly rare. Far more pressing for our > user base is the need to guarantee a hassle-free 100% valid export to a > "sanitized word format" which is narrowly restricted, on both sides, to > the semantic information contained in LyX. > > To put it more bluntly (and to repeat what I and others have stated many > times in the past): LyX is barely usable right now for any academic > work in the Humanities, due to the necessity to deliver doc documents to > virtually any publisher. If you are a student, you are similarly asked > by professor to submit drafts in Word format. > > I had t
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On 02/09/14, 19:44 , Georg Baum wrote: > Rainer M Krug wrote: > >> The idea would be that a round-trip framework is envisaged, which >> provides the facilities to easily expand it from one export backend >> (docx) to another (possibly odt? markdown?). >> >> IMPORTANT: this would NOT change ANYTHING in the existing export / >> import features, as these are geared to export / import the documents as >> good as possible, with maintaining as many features as possible in the >> document. >> >> The round-trip would guarantee that: >> >> A document authored in LyX would result in a e.g. docx with a LIMITED >> set of features, but that a re-import would result in the SAME .lyx >> file. features and formats not supported by the backend should be stored >> in a metadata file. >> >> The important point here is *limited set of features*! >> >> In addition, the framework should be easily, possibly only by using >> config files, able to be extended to other formats. > > I don't understand the difference between round trip and the existing > export/import here. Why is it important? If the additional metadata is > stored in a different file, it could simply be generated for the standard > export, and be used by the standard import (if it exists). > > The goal of the export/import is to support as many features as possible. > This is needed for round trip as well. The only difference I see is the > additional metadata file, so the roundtrip framework vs. export/import > difference reduces to a switch whether the metadata file should be generated > (for export) or used (for import). Or did I understand anything wrong? The difference is that for round-trip, i.e. working together with co-authors and getting comments back, a different set of features are relevant. These are mainly concerned about content and not that much formating. The import - export is concerned with both. In addition, a round trip has to be symmetric, i.e. that exported features have to be available in the re-importd as well - this is not the case in the export and import. Lastly, round-trip is for editing, and export - import is for editing and final consumption (reading). > >> Yes - although I see one problem which I could not find in any of the >> .lyx <-> .docx : comments and track changes. These *have to be handled*. >> I somehow have the feeling, that an inclusion of comments and track >> changes into pandoc would be the best way forward... > > I agree. Unfortunately pandoc is written in Haskell which reduces the number > of possible contributors significantly (which does not mean that Haskell is > a bad language, but that it is much less known than e.g. C++ or python). True. Cheers, Rainer > > > Georg > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On 02/07/14, 17:35 , Rob Oakes wrote: > Hi all, Hi Rob, good to hear from you on this topic. > > I have been following conversations with significant interest. I > started a new job in the middle of last year. That combined with an > 18-month old little boy have left me almost no time for > extracurriculars. There is no way I can realistically mentor a student > this year. I tried really hard last year, and the effor didn't turn out > quite so well. > > With that said, I would be happy to provide some support to a student > who might be trying to work on a round-trip Python module, or on the > non-linear writing project. If someone else were to be primary mentor, > I could certainly answer questions. > > Re: Round-Tripping > > As others in the thread have mentioned, I think the magic happens in > the export from LyX to Word. There are places where meta-data can be > placed in DOCX so that we can try and preserve LyX-specific features > through a round trip; and if we focus on semantic markup only, I think > we can do a pretty good job of maintaining content. This is exactly what I think the round-triop has to focus on: semantic markup to maintain the content and to have it available after edits for re-import. > > I think this means that we would need our own library to handle the > export. Most of the other modules out there do a very poor job of > handling semantic markup, and instead try and get the styling right. > That way madness lies. The Python module I started hacking on for the > import provides some support for generating docx, but this would need > to be beefed up pretty heavily. Moreover, it would be a really good > idea to make use of XSLT stylesheets to handle the transformation from > docx to LyX, instead of the Python approach I took. This is why I also think that round-trip is a different story then export - import. Different aspects of the document are relevant and need to be preserved. > > On another note, you should also probably have a discussion about how > you want to handle maths. The math XML vocabulary in docx is pretty > well contained, but it would still be an enormous job to translate it > to LyX/LaTeX. For export, we might make use of the MathML support LyX > already supports, and then translate thtat to docx math XML. There may > even be XSLT to do that. I can't comment here, but I think that it would be nice to have this, and in many cases this might be absolutely essential, but it could be addad at a later stage, when the basic round-trip features are in place. But it should definitely be considered. Cheers, Rainer > > Cheers, > > Rob > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On 02/09/14, 20:25 , Georg Baum wrote: > Rainer M Krug wrote: > >> On 02/07/14, 10:49 , Vincent van Ravesteijn wrote: >>> On Fri, Feb 7, 2014 at 10:02 AM, Rainer M Krug wrote: >>> >>>> The idea would be that a round-trip framework is envisaged, which >>>> provides the facilities to easily expand it from one export backend >>>> (docx) to another (possibly odt? markdown?). >>> >>> This sounds like a sort of testing framework which would indicate for >>> each export backend which features are exported and imported >>> successfully. It would be cool to have some matrix showing how mature >>> each of the supported formats is. >> >> Nicely put! That would be brilliant. Not only formats, but converters: >> different converters convert different features. > > Yes, such a matrix would indeed be a nice tool. > >>> Would this also solve some of the LyX->LaTeX->LyX roundtrip issues ? > > Some, but I believe not many. The main LyX->LaTeX->LyX problems come from > the fact that LaTeX as a macro language is really ugly to parse. Only some > of them come from the fact that the exported LaTeX contains less information > than the original LyX file. One feature where additional metadata would > definitely help are branches. > >> Partly - if the export to LaTeX is split from the round trip LyX <-> >> LaTeX I would say yes, with the caveat, that only a subset of features >> would be supported by the round trip. In contrast, export - import would >> (hopefully sometime in the case of import from LaTeX) the full set of >> LyX and LaTeX features with (possibly ugly in LyX) the export / import. > > This is not possible. There are LyX features that simply do not appear in > the exported LaTeX, so they can't be imported (e.g. branches or notes). It > might be possible to support all LaTeX features, but the cost would be > extremely high, so there will always be LaTeX files which can't be imported > (usually the stuff found in .cls or .sty files). OK - in this regard you are right - haven't considered branches. But LyX notes could be exported as LaTeX comments starting with %%LyX-Note%%. Branches: isn't there conditional compiling in LaTeX? In this way branches could be kept and switched by activating these in the preamble? > >> So: yes, the round-trip framework could be used for a subset of features >> initially for LyX <-> LaTeX, which can then be extended over time - I >> guess this would be the easiest to start with, actually. > > This does not make sense IMHO. Why artificially restrict the roundtrip? Because, as you said above, some features in LyX can not be exported into LaTeX and the other way round? In addition, the round-trip would be needed to mainly edit content, and not that much formating - how a section header looks in word or in LyX is irrelevant, as long as it is recognised in the re-import / re-export for round-trip as a section header. In Contrast, when exporting (non-round trip) one wants a document as similar as possible to the LyX / LaTeX pdf (in most cases). > > The LyX->LaTeX->LyX roundtrip is special in the sense that the LaTeX->LyX > step is very tightly integrated with LyX. Therefore it is indeed a good > starting point, but not in the way of splitting off a separate roundtrip, > but by extending the existing export/import with the additional metadata > file you mentioned. The advantage would be that you would not need to put > too much stuff into the metadata file, so it would be clear quickly the > general approach works. You are right - LaTeX is a special case, as it is the default backend for LyX. So there are more strict requirements for the round-trip, and all improvements in the round-trip should be immediately in the LaTeX importer as well. But the story is different with other backends, e.g. docx, where, if you go to replicating the LaTeX view, you might end with "painted" documents which are not easily to be re-imported into LyX. But for round trip, the look is not that relevant, as long as the content and the structure can be re-imported. Rainer > > > Georg > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On 02/07/14, 11:11 , Cyrille Artho wrote: > Dear all, > I think we have had earlier discussions (a few months ago) that touched > some of the problems, but I see some major challenges when having a > roundtrip conversion where extra data cannot be stored in the target > file itself. To quote Coldplay and Willie Nelson (From "The Scientist"): Nobody said it was easy No one ever said it would be this hard True - we had this discussion before and this is what the entry on the wiki is based on. I agree that there are big difficulties, and especially on the "dark side" (read: the side we are exporting to) as we have no control over it. > > The issue is that the target file will be edited before it's re-imported > (otherwise there is no point in exporting the data to being with). This > can make a clean re-import very challenging. Absolutely. > > For example: > > "Good": lyx -> latex: Store extra data as special LaTeX comments. > > A comment at the beginning of the file can let a LaTeX user know that > some features (starting with %%LyX or such) should not be edited, > because details are lost otherwise. > > The reverse conversion should work well even if the LaTeX file is > changed a lot, as a normal user can be expected to leave the extra > comments where they belong. > Exactly - that is what one can hope for. > > "Bad": lyx -> something rather alien (.docx or such): If you need to > store information in other files, how are the parts going to be > reconstituted after the .docx file has been changed? Same way probably? Using notes and comments, convert these to LyX, as they have a location, they will stay where they are, the post-process the LyX file by applying the %%LyX notes? > > > Regardless of the number of files, the problem is much harder than just > a reversible mapping. It has to survive a certain amount of editing. The > same edits in the original and in the exported version should map to the > same result after re-importing: > >file - > lyx2target -> target > > | | > | edit | edit > V V > >file' <- target2lyx <- target' > I have no idea how this can be done elegantly, but I hope this can be made easier by a) using some type of tags in comments / notes / et al which all programs have and b) a certain discipline by the person editing the documents by not deleting these. This applies to the LaTeX user as well as the Word user. Nothing is foolproof. > > At least for some editing, this should be supported. I don't think it is > necessary to be perfect here, so it can probably be achieved for many > useful practical cases, but I also think it's harder than just > converting back and forth. > You are definitely right here, and that is the reason why this proposal / idea sounds quite vague: it is a difficult problem (especially as I think one should keep the structure very flexible, so that it will be easy to support different backends) and there is no control over the other side of the roundtrip. In LyX one could restrict the features usable, display warnings on ex[port for roundtrip, etc. But there is no way this can be done in e.g. word or LaTeX. And I agree: one has to start with a small subset of features supported, and then they can be extended. That is why on http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014#toc1 there is a list of *suggested* features: Features to be included in the round trip are: sections, headers, ... lists emphasis, bold, ... comments track changes tables and figures? footnotes bibliographic references math? cross-references #### So I see the difficulties, but a system like this would be tremendously useful to support roundtrips to many different backends. Cheers, Rainer > > > Vincent van Ravesteijn wrote: >> On Fri, Feb 7, 2014 at 10:02 AM, Rainer M Krug wrote: >> >>> The idea would be that a round-trip framework is envisaged, which >>> provides the facilities to easily expand it from one export backend >>> (docx) to another (possibly odt? markdown?). >> >> This sounds like a sort of testing framework which would indicate for >> each export backend which features are exported and imported >> successfully. It would be cool to have some matrix showing how mature >> each of the supported formats is. >> >> >>>> >>>> Perhaps we could define the goals as: >>>> >>>> 1. Define a minimal-lyx feature set (I.e. the supported LyX/LaTeX >>>> features) >>> >>> Agreed. >>> >>>> 2. Write a corresponding lyx-layout >
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On 02/07/14, 10:49 , Vincent van Ravesteijn wrote: > On Fri, Feb 7, 2014 at 10:02 AM, Rainer M Krug wrote: > >> The idea would be that a round-trip framework is envisaged, which >> provides the facilities to easily expand it from one export backend >> (docx) to another (possibly odt? markdown?). > > This sounds like a sort of testing framework which would indicate for > each export backend which features are exported and imported > successfully. It would be cool to have some matrix showing how mature > each of the supported formats is. Nicely put! That would be brilliant. Not only formats, but converters: different converters convert different features. > > >>> >>> Perhaps we could define the goals as: >>> >>> 1. Define a minimal-lyx feature set (I.e. the supported LyX/LaTeX features) >> >> Agreed. >> >>> 2. Write a corresponding lyx-layout >> >> As I said, non-supported formats / features should be available to the >> user and handled gracefully, i.e. stored in a metadata file which will >> be re-applied when re-iporting the round-trip file. >> > > Would this also solve some of the LyX->LaTeX->LyX roundtrip issues ? Partly - if the export to LaTeX is split from the round trip LyX <-> LaTeX I would say yes, with the caveat, that only a subset of features would be supported by the round trip. In contrast, export - import would (hopefully sometime in the case of import from LaTeX) the full set of LyX and LaTeX features with (possibly ugly in LyX) the export / import. So: yes, the round-trip framework could be used for a subset of features initially for LyX <-> LaTeX, which can then be extended over time - I guess this would be the easiest to start with, actually. > >> >> Yes - although I see one problem which I could not find in any of the >> .lyx <-> .docx : comments and track changes. These *have to be handled*. >> I somehow have the feeling, that an inclusion of comments and track >> changes into pandoc would be the best way forward... > > What is the problem you see ? With pandoc? Actually none, only that the development work would need to be done in pandoc and not LyX. > > Vincent > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
As I was one of the ones who initially raised this issue, let me coment on it. On 02/06/14, 18:35 , stefano franchi wrote: > The first project in our wiki page for GSOC 2014: > > http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014 > > is, at the same time, the most ambitious and the least well-defined > (possibly because the former implies the latter). Exactly - this was thought of as a starting point to develop a GSoC project - so it is not complete, but could also be split into different aspects which can be treated separately. > > It is not clear to me if this a coding project or if it defines the > outline of a preliminary non-coding feasibility study that would, at > most, produce a document describing the minimal-lyx and minimal-docx > feature sets (plus, possibly, a minimal-lyx-layout and a > minimal-doc-template). Well - the entry is about the mainly non-coding framework, and the project would be about implementing it. > > Any thought on how to make it more focused? The idea would be that a round-trip framework is envisaged, which provides the facilities to easily expand it from one export backend (docx) to another (possibly odt? markdown?). IMPORTANT: this would NOT change ANYTHING in the existing export / import features, as these are geared to export / import the documents as good as possible, with maintaining as many features as possible in the document. The round-trip would guarantee that: A document authored in LyX would result in a e.g. docx with a LIMITED set of features, but that a re-import would result in the SAME .lyx file. features and formats not supported by the backend should be stored in a metadata file. The important point here is *limited set of features*! In addition, the framework should be easily, possibly only by using config files, able to be extended to other formats. > > Perhaps we could define the goals as: > > 1. Define a minimal-lyx feature set (I.e. the supported LyX/LaTeX features) Agreed. > 2. Write a corresponding lyx-layout As I said, non-supported formats / features should be available to the user and handled gracefully, i.e. stored in a metadata file which will be re-applied when re-iporting the round-trip file. > 3. Define a minimal-doc feature set (Word/ODF features corresponding to (1) Yes - but these have to be the same as in 1). > 4, Write a Word/OO template (the set of styles corresponding to 2) Might be a good idea. > 5. Provide an automated path from 1 to 4 and back using glue-code and > existing internal and external tools (e.g.: LyX export functions to > XHTML/EPub, eLyxer, pandoc, writer2latex, etc). Yes - although I see one problem which I could not find in any of the .lyx <-> .docx : comments and track changes. These *have to be handled*. I somehow have the feeling, that an inclusion of comments and track changes into pandoc would be the best way forward... > > I am not sure points 1-5 above capture the existing description, partly > because I am not sure about what is meant by "develop a framework". > Perhaps my summary caputeres the subgoal only? Well - "framework" in the sense that the coded "framework" would not be specific to .lyx <-> .docx but that it would be applicable to other export backends as well: Roundtrip from lyx: .lyx --> extract non-maintained formats / features and store these in metadata / sidecar file (based on converter X) --> convert .lyx to .??? using converter X .??? and back after the .??? has been edited: .??? --> extract non-maintained formats / features and store these in metadata / sidecar file (based on converter Y) --> convert .??? to .lyx --> apply formats from metadata / sidecar file .lyx and back to .??? after editing: .lyx --> extract non-maintained formats / features and store these in metadata / sidecar file (based on converter X) --> convert .lyx to .??? using converter X --> it would be great if there is a way of applying the sidecar file, but I think this won't be possible .??? Hope this clarifies some questions, Rainer > > Stefano > > > -- > __ > Stefano Franchi > Associate Research Professor > Department of Hispanic Studies Ph: +1 (979) 845-2125 > Texas A&M University Fax: +1 (979) 845-6421 > College Station, Texas, USA > > stef...@tamu.edu <mailto:stef...@tamu.edu> > http://stefano.cleinias.org -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug signature.asc Description: OpenPGP digital signature
Re: Facilitate testing on OSX - WAS: menu bar lost in OS X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/14, 11:07 , Stephan Witt wrote: > Am 03.02.2014 um 10:56 schrieb Rainer M Krug : > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> >> >> On 01/31/14, 20:28 , Rainer M Krug wrote: >>> >>> >>> Le vendredi 31 janvier 2014, Richard Heck >> <mailto:rgh...@lyx.org>> a écrit : >>> >>> On 01/30/2014 03:04 AM, Rainer M Krug wrote: >>> >>> On 01/29/14, 02:41 , Richard Heck wrote: >>> >>> On 01/28/2014 03:14 PM, Scott Kostyshak wrote: >>> >>> This should be fixed shortly and a new installer will be >>> uploaded. >>> >>> As often, this is due to changes in the underlying Qt platform >>> that seem to exist only on certain versions of OSX. We have had >>> this problem before, and there are other issues about Cocoa >>> versus whatever versus whatever else. It is difficult to test >>> every combination, and we have only a couple active OSX >>> developers. Many of them use trunk (2.1.dev) for obvious sorts >>> of reasons. So, well, we could really use a couple people who >>> could test the OSX version on a more regular basis. >>> >>> To facilitate this, may I suggest to create a homebrew recipe >>> to facilitate the installation and update of the latest LyX? At >>> least for me, I would likely use (and update) it regularly as >>> it is no hassle at all (in contrast to downloading and >>> installing, or even compiling first. >>> >>> >>> This is a great idea, but of course someone on OSX who knew how >>> to use homebrew would need to do it. >>> >>> >>> I'll ask on the homebrew list if there would somebody be >>> interested in helping. But apparently, it is not that >>> difficult. >> >> I am using this to the devel lits as this does not (yet?) concern >> a "normal" user. >> >> Looking into this, I am wondering: what are the settings to >> create the LyX binary for Mac? I could not find a hotwo on how to >> compile on mac? > > Possibly a little bit outdated - but did you consider > INSTALL.MacOSX? Shame on me - there it is, in the obvious place. Thanks, I'll look into it, Rainer > > Stephan > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS73C6AAoJENvXNx4PUvmC6WYIALVbED9DGwDNo5x7gYpImJCZ 38UW5FRanH8vB5//i6KKBNFsT6/bNCBp4gcR0LjdppGWgM1fgnCBw+TUtDLDPL3j FYOw7D71+5lQAMT+ZgkVwQX0hrGCF2AJa1vYEUfJygrSv48VrMHDdYpCaLAw/zj6 imqgk/rx6pzaml3otn+BdqGIFzrkhLkfeS+VF08WIWXBhcLOZDG1EFLhBzgagLsd FP1PI3b0jH8O5xKu5UHrxGCVjVOOx1ZG7hhOXz5EknaPtgGaaOEUc3mdlfpfjIXR TFD0F47n8jpuGHSqjAJ1EARvUKqZaijQkDnafE0gL9asvscqplSehQaZuzn9Jns= =stBe -END PGP SIGNATURE-
Re: LyX Beta Mac install - include version in app name?
Stephan Witt writes: > Am 09.09.2013 um 11:27 schrieb Rainer M Krug : > >> Hi >> >> I would like to test the LyX beta, but would like to have it alongside >> the regular LyX installation. Under Ubuntu, the version name was >> included in the application name - would this be possible for Mac as >> well? In addition, this would make it easily possible to have several >> versions installed at the same time, or is simply renaming the app >> folder enough? > > Yes, simply rename the app. > There is no need to add the version string to the app name. Thanks, Rainer > > Stephan > -- Rainer M. Krug email: RMKruggmailcom
LyX Beta Mac install - include version in app name?
Hi I would like to test the LyX beta, but would like to have it alongside the regular LyX installation. Under Ubuntu, the version name was included in the application name - would this be possible for Mac as well? In addition, this would make it easily possible to have several versions installed at the same time, or is simply renaming the app folder enough? Thanks, Rainer -- Rainer M. Krug email: RMKruggmailcom pgp0_DqUcJpzt.pgp Description: PGP signature
LyX on Retina display
Don't know if it is relevant - but I just found this http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/ about qt support for high resolution displays (incl Retina). Might this help to make LyX nicer on e Retina display? Cheers, Rainer -- Rainer M. Krug email: RMKruggmailcom pgp86TrS98yRb.pgp Description: PGP signature
Re: [Proposition] Organizing templates and user examples
On Wednesday, May 15, 2013, Liviu Andronic wrote: > On Wed, May 15, 2013 at 10:11 PM, Alex Vergara Gil > > > wrote: > > IMHO, the default localization for user examples outside the template > folder > > creates an annoying workflow for users which must go up to the root > folder > > then go to the examples. > > > +1 +1 Rainer > > Liviu > > > > On the other hand each time I want to upgrade LyX I > > must waste my time sincyng the default locations with my predefined ones. > > > > Which I propose is simple > > > > Templates are every file that create an approach to a result, tested or > not, > > so there must be an unique folder for templates, inside it there must be > at > > least three folders use whatever name you want but I prefer: "main" > (refered > > to release templates, currently "templates" folder), "testing" (refered > for > > non release or under revision templates, currently "examples" folder) and > > "user" (refered for user made templates, this should go inside user > account > > but should also be visible when you do "file"-"new from template"). In > this > > way order will be achieved, you can have experimental templates and users > > will not complain about where to find the "moderncv" template for > instance > > (personal experience with LyX-2.0.4 under Windows). There are also > further > > improvements like folders for each kind of template but at this point I > > think they are not necesary. > > > > Best regards > > Alex Vergara > > > > -- > Do you know how to read? > http://www.alienetworks.com/srtest.cfm > http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader > Do you know how to write? > http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: Idea for and open source project for GSOC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cyrille Artho writes: > Hi Peter, Hi Peter interesting idea. I neither use nor know it enough to give comments on it itself, but I would like to pint out a few aspects which would be very useful for LyX: 1) the showing of error messages is very useful for many text based graphics. You mention tikz: I think that is reasonably widely used within LyX, so that a better integration would be useful and would likely find supporters. 2) integration into LyX: I would think about the converters or in instant preview where this could fit in. 3) I am using e.g. plantuml [1] to generate graphs - would it be possible to abstract your program to such an extent that it would use that as well? 4) Just a suggestion: I would change the name MetaView - there are to many other companies called metaview so that you won't find it via google. Cheers, Rainer Footnotes: [1] html://plantuml.sourceforge.net/ > I am not familiar with MetaPost, but your project sounds > interesting. Is the code for your tool already available? Note that > your code must be released under one of the GSoC-approved open source > licenses to be acceptable for GSoC. > > To get support from the LyX community, you may consider integration of > your tool into LyX as the summer project. That ensures a strong link > to LyX. Other ideas are of course also welcome, as long as they are > feasible within 2 - 3 months and have a clear project plan. > > Peter Zeman wrote: >> Hello. >> >> A few days ago I wrote an email, but I didn't get a response to my >> mentor request. So now I would like to ask again. I would like to >> know, whether my idea has a chance to be accepted by your >> organization. Your organization is the closest to the topic of my >> project. >> >> What is my project about? >> >> The purpose is to speed up the development of images in MetaPost. The >> standard workflow is that you repeatedly compile your Metapost and TeX >> file, to view the current state of the images. It is quite slow and >> tedious, when you have to view the output after each edit of some >> MetaPost file and when some mistakes occur, it takes quite some time >> to detect it and fix it. >> >> The purpose of my program called MetaView is to show immediately the >> image you are currently working on. Whenever you update the Metapost >> source file, the image is automatically compiled and displayed. If the >> compilation fails, it displays the error message immediately. The >> program will also contain many other features. It is important that >> the user can use any text editor for editing the Metapost file; there >> are some similar programs with build-in editors, but those are not >> convenient. Currently it works only with Metapost, but there should be >> no problem to make it work with something similar like TikZ or >> Asymptote. >> >> To make everything clear, I made some screenshots, so that you can >> imagine how the workflow looks like with MetaView. The second >> screenshot shows what happens when an error occurs in the Metapost >> source file. Note that much work has to be done. >> >> http://atrey.karlin.mff.cuni.cz/~pizet/metaview_workflow.png >> http://atrey.karlin.mff.cuni.cz/~pizet/metaview_error.png >> >> I would be very happy to hear your opinion. >> >>Peter Zeman - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRdjnNAAoJENvXNx4PUvmCFNUH+QG5TURGprE4X94rBufK9qM6 JNTnr4H7WvAugFjnyGrA8IghDxKlhw5Tgb9VG93jZgHMZwekTYLXZFN8bNTxh6Ot 4tBEulQHjdoM+QbSKGKthXSlY3h4fpexyy0+qD7VpTkgP2Muebsuv+5LPKAb+Nz5 mt+Cof9wuLuKyzhDiWy7t17tuvyCxJ5d62A/+ljEUDmn8VoJjdlJtHuyzm+zj5V3 LSPQAW6WtV4mLS6eyYLGWXOkyTuqRw10Ti6SVuaqtNyepG1ik4E8Cy7F4vH+XoaV XP+3SEm7GX6xbHpd5dhAaLYY6xIzNtyvPf+SN4snkzHcE7sZleuP6XV9GE2gVWQ= =45Ew -END PGP SIGNATURE-
Re: improve latex-lyx roundtripping (GSoC)
Cyrille Artho writes: > Sounds reasonable. I would recommend, though, that no information is > duplicated across files. If LyX is used to edit a "pure tex" document, > then a separate lyx-specific file should keep only additional > information, to avoid duplication of contents. Also, the extra file > would be kept under revision control as well, as there may be multiple > LyX and multiple TeX users working on the same document. Absolutely - duplication is bad, as it can (will?) lead to problems in the roundtrip: if the info is changed in the tex (or docx) file and not in the lyx-specific file, there will be problems on re-import. Let me re-iterate another point which was made earlier (unfortunately I don't remember the thread): these discussions are effectively independent of the second format in the round-trip: if it is tex, docx, rtf, even txt - the basic discussion is the same. What is different, is a) the set of features which can be maintained in the target format (tex, docx, rtf, txt even, ...) b) the actual creation of the content file (tex, docx, rtf, ...) If this is designed right, I think one get an incredibly powerful framework which can easily be extended to be used for other text formats. Cheers, Rainer > > Rainer M. Krug wrote: >> Cyrille Artho writes: >> >>> Hi Guenter, >>> I would assume that only a LaTeX source file is kept, no other files. >>> With a strategy of having multiple files, there are other issues. I >>> would prefer having one file for everything, but I am interested to >>> hear arguments for the other case; maybe I can be convinced that >>> multiple files (LaTeX + LyX-specific features) are better :-) >> >> There is one strong argument for having multiple files: One can send a >> "clean" tex (or docx as suggested in another thread) to the co-authors >> and keep the additional files (in an archive probably?) local. They can >> not be corrupted, lost or deleted as it would be relatively easy if >> these would be part in one tex file. Additionally, as a tex document >> does usually consist anyway of multiple files (the .tex file, often .bib >> files and images, ...) I don't think it is a big problem to have one >> more. >> >> Cheers, >> >> Rainer >> >>> >>> Guenter Milde wrote: >>>> On 2013-04-20, Georg Baum wrote: >>>>> Cyrille Artho wrote: >>>> >>>>>> I'm not familiar enough with the capabilities of LaTeX macros to be the >>>>>> final judge on that, but it seems plausible that macros may work better >>>>>> for many features. >>>> >>>>>> However, it is also desirable to keep the LaTeX code simple. For features >>>>>> that are merely related to displaying things (inset open/collapsed, "lyx >>>>>> zoom" factor for images), a comment may indeed be the simplest way. If >>>>>> the >>>>>> comment is garbled or lost, the default (inset open, 100 % zoom) applies. >>>> >>>> Actually, I would not like LyX GUI settings to turn up in the LaTeX file at >>>> all. Non-LyX workers will be offended, others can restore them, and in the >>>> most asked for application of the round-trip feature -- editing in the >>>> Source View -- this is not required as LyX can keep the GUI settings. >>>> >>>> Günter >>>> >> <#secure method=pgpmime mode=sign> >> > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug pgpyEazd6ZouR.pgp Description: PGP signature
Re: improve latex-lyx roundtripping (GSoC)
Cyrille Artho writes: > Hi Guenter, > I would assume that only a LaTeX source file is kept, no other files. > With a strategy of having multiple files, there are other issues. I > would prefer having one file for everything, but I am interested to > hear arguments for the other case; maybe I can be convinced that > multiple files (LaTeX + LyX-specific features) are better :-) There is one strong argument for having multiple files: One can send a "clean" tex (or docx as suggested in another thread) to the co-authors and keep the additional files (in an archive probably?) local. They can not be corrupted, lost or deleted as it would be relatively easy if these would be part in one tex file. Additionally, as a tex document does usually consist anyway of multiple files (the .tex file, often .bib files and images, ...) I don't think it is a big problem to have one more. Cheers, Rainer > > Guenter Milde wrote: >> On 2013-04-20, Georg Baum wrote: >>> Cyrille Artho wrote: >> >>>> I'm not familiar enough with the capabilities of LaTeX macros to be the >>>> final judge on that, but it seems plausible that macros may work better >>>> for many features. >> >>>> However, it is also desirable to keep the LaTeX code simple. For features >>>> that are merely related to displaying things (inset open/collapsed, "lyx >>>> zoom" factor for images), a comment may indeed be the simplest way. If the >>>> comment is garbled or lost, the default (inset open, 100 % zoom) applies. >> >> Actually, I would not like LyX GUI settings to turn up in the LaTeX file at >> all. Non-LyX workers will be offended, others can restore them, and in the >> most asked for application of the round-trip feature -- editing in the >> Source View -- this is not required as LyX can keep the GUI settings. >> >> Günter >> <#secure method=pgpmime mode=sign> -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: docx roundtrip
Daniel Vainsencher writes: > I would suggest some connections between seemingly different projects > here: I agree that they could be liked, especially in regards to the underlying infrastructure needed for a roundtrip. > 1. For round tripping, there is a close link between the exporter and > importer, because the importer must understand, in addition to the > external format, the side information provided by the exporter (say, > math-macro defs). Exactly. And especially because of this reason, I don't think the round-trip converter should be identical to the one-way exporter. A one-way exporter will (should?) always be better in converting one-way-only without a reasonably simple way back, because it will try to write everything in exactly the format used by the target format. On the other hand, the round trip converter will only convert a subset as good as possible, and keep the rest in meta information for return import. So these two have a different aim. > 2. The structure of a round-trip exporter-importer may be similar > between different external formats. Up to a certain point, as round-trip via LaTeX will be able to include many more features then round-trip via docx. But it should be possible to embed these two in the same framework. > > So it might be useful to describe this project as "round-trip > collaboration", giving latex and some other format (say, docx) as the > first two goals instances, but designing it with a hope for > generality. I think that would be an excellent idea, as it would make using new formats easier in the future then developing everything new. Sounds like a very useful project idea to me. Cheers, Rainer > It is sometimes said that design for a general case should > occur after solving three particular instances, but I hope someone > with more technical LyX background will chime in. > > Daniel > > On 04/18/2013 12:52 PM, Rainer M. Krug wrote: > > stefano franchi writes: > > > On Thu, Apr 18, 2013 at 9:50 AM, Rainer M. Krug > wrote: > > > Liviu Andronic writes: > > > Dear Daniel, > > > On Sun, Apr 14, 2013 at 10:26 AM, Daniel Vainsencher > wrote: > > > Please CC me on answers. > > I often collaborate with people who (still) prefer LaTeX, and also > > submit > > > papers to conferences that make it easy to submit latex > via > style/class/sample.tex files. This makes it important to be able to > > work in > > > LyX, but debug/modify in latex, then continue working in > LyX. > > I would strongly agree with this. Round-tripping LyX <--> > LaTeX > documents is one of the long-term goals of LyX. And in my > understanding this is something that lies in the realm of achievable. > What we need is, mostly, for a devel or student to show more love to > the tex2lyx conversion routines. > > > > It would probably be difficult to preserve latex source > formatting etc, > > and > > > I am not proposing that; I am assuming the main source of > content is > > LyX. > > > > Two particular features would make this easier: > > - Math-macros, if turned into \global\long\def, should be turned back so > LyX's beautiful visual editing is restored (can keep the math-macro def > > in a > > > comment in the latex version and restore it). > BTW, when does a math-macro become a \newcommand vs \global\long\def? > > - Automatically generate styles for environments defined in imported > documents. For example if the imported latex has a keywords environment, > that should not suddenly become ERT in LyX. > This should allow me to start from the conference sample file, import it > into LyX, and obtain a first class lyx environment. > > Both your suggestions look useful, although I'm wondering how > achievable is the 2nd one. I'd love to hear what established devels > think of this. > > Either way, I think this is a project worthy for GSoC and if you can > come up with a suitably worded project proposal feel free to place it > here: http://wiki.lyx.org/Devel/SummerOfCode2013Ideas (and let us know > on lyx-devel). This would greatly increase the chances of a student > picking it up. And if we have no student for such a project this year, > we should certainly consider it f
Re: docx roundtrip
Liviu Andronic writes: > On Thu, Apr 18, 2013 at 10:50 AM, stefano franchi > wrote: >>> While we are talking about roundtrip - there is still the dreaded issue >>> of MS Word (docx) roundtrip. >>> >>> There is again and again the discussion coming up of exporting to docx >>> and importing docx, and (especially in the humanities as I gather from >>> these discussions) many journals only accept doc / docx for submission. >>> >> >> Absolutely! A minimum level of compatibility with MS Word (or openOffice) >> would be a great boon to LyX. Actually, I think roundtripping, while >> desirable is probably out of reach for even moderately complex documents. >> What is really needed is a decent LyX --> doc export filter, and precisely >> for the reasons Rainer mentioned: most publishers in the humanities accept >> .doc only. Ideally, an export filter to doc should preserve semantically >> relevant formatting (emphasis, footnotes, refs, cross-ref, and little else) >> and discard everything else. >> > Maybe that's worth a GSoC project by itself? Anyways, I remember Rob See my response to Daniel, because his ideas are similar to mine in this regard. > has done some work on this: > http://blog.oak-tree.us/index.php/2010/05/14/msword-lyx-import > http://www.oak-tree.us/2012/03/07/word2lyx01-2/ > > but the links are currently not responsive. Maybe a student could > build on that. As far as I remember, he was only working on an importer from docx - not an exporter - but I guess a student could pick up from there. Rainer > > Regards, > Liviu -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: docx roundtrip
stefano franchi writes: > On Thu, Apr 18, 2013 at 9:50 AM, Rainer M. Krug wrote: > >> Liviu Andronic writes: >> >> > Dear Daniel, >> > >> > >> > On Sun, Apr 14, 2013 at 10:26 AM, Daniel Vainsencher >> > wrote: >> >> Please CC me on answers. >> >> >> >> I often collaborate with people who (still) prefer LaTeX, and also >> submit >> >> papers to conferences that make it easy to submit latex via >> >> style/class/sample.tex files. This makes it important to be able to >> work in >> >> LyX, but debug/modify in latex, then continue working in LyX. >> >> >> > I would strongly agree with this. Round-tripping LyX <--> LaTeX >> > documents is one of the long-term goals of LyX. And in my >> > understanding this is something that lies in the realm of achievable. >> > What we need is, mostly, for a devel or student to show more love to >> > the tex2lyx conversion routines. >> > >> > >> >> It would probably be difficult to preserve latex source formatting etc, >> and >> >> I am not proposing that; I am assuming the main source of content is >> LyX. >> >> >> >> Two particular features would make this easier: >> >> >> >> - Math-macros, if turned into \global\long\def, should be turned back so >> >> LyX's beautiful visual editing is restored (can keep the math-macro def >> in a >> >> comment in the latex version and restore it). >> >> BTW, when does a math-macro become a \newcommand vs \global\long\def? >> >> >> >> - Automatically generate styles for environments defined in imported >> >> documents. For example if the imported latex has a keywords environment, >> >> that should not suddenly become ERT in LyX. >> >> This should allow me to start from the conference sample file, import it >> >> into LyX, and obtain a first class lyx environment. >> >> >> > Both your suggestions look useful, although I'm wondering how >> > achievable is the 2nd one. I'd love to hear what established devels >> > think of this. >> > >> > Either way, I think this is a project worthy for GSoC and if you can >> > come up with a suitably worded project proposal feel free to place it >> > here: http://wiki.lyx.org/Devel/SummerOfCode2013Ideas (and let us know >> > on lyx-devel). This would greatly increase the chances of a student >> > picking it up. And if we have no student for such a project this year, >> > we should certainly consider it for subsequent GSoC summers. >> >> While we are talking about roundtrip - there is still the dreaded issue >> of MS Word (docx) roundtrip. >> >> There is again and again the discussion coming up of exporting to docx >> and importing docx, and (especially in the humanities as I gather from >> these discussions) many journals only accept doc / docx for submission. >> >> > Absolutely! A minimum level of compatibility with MS Word (or openOffice) > would be a great boon to LyX. Actually, I think roundtripping, while Sorry - haven't mentioned openOffice / LibreOffice. But I encountered quite a few problrms with their odt - docx - odt conversions, that I think an .lyx -> .odt converter is a different story. > desirable is probably out of reach for even moderately complex > documents. I don't know enough about the docx format, but as you say below, if one 1) defines a set of desired features for the roundtrip 2) agrees on a way on how to deal with the other features (putting them in comment sections or accompanying second file, so that they can be re-applied on the re-import?) 3) uses these guidelines to develop the round-trip converter lyx -> docx and docx -> lyx it should be doable and possible to grow the converters over time y adding new features supported. Even a warning of non-supported formating features would relatively easy to accomplish (do the round-trip and see). > What is really needed is a decent LyX --> doc export filter, and precisely > for the reasons Rainer mentioned: most publishers in the humanities accept > .doc only. Ideally, an export filter to doc should preserve semantically > relevant formatting (emphasis, footnotes, refs, cross-ref, and little else) > and discard everything else. I can not agree more - but that could be separate from the round-trip converters. A non-round-trip converter could be present to convert as many features as possible *without* round-trip support. Rainer > > Stefano > > > > >> Not only the jo
docx roundtrip WAS: improve latex-lyx roundtripping (GSoC)
Liviu Andronic writes: > Dear Daniel, > > > On Sun, Apr 14, 2013 at 10:26 AM, Daniel Vainsencher > wrote: >> Please CC me on answers. >> >> I often collaborate with people who (still) prefer LaTeX, and also submit >> papers to conferences that make it easy to submit latex via >> style/class/sample.tex files. This makes it important to be able to work in >> LyX, but debug/modify in latex, then continue working in LyX. >> > I would strongly agree with this. Round-tripping LyX <--> LaTeX > documents is one of the long-term goals of LyX. And in my > understanding this is something that lies in the realm of achievable. > What we need is, mostly, for a devel or student to show more love to > the tex2lyx conversion routines. > > >> It would probably be difficult to preserve latex source formatting etc, and >> I am not proposing that; I am assuming the main source of content is LyX. >> >> Two particular features would make this easier: >> >> - Math-macros, if turned into \global\long\def, should be turned back so >> LyX's beautiful visual editing is restored (can keep the math-macro def in a >> comment in the latex version and restore it). >> BTW, when does a math-macro become a \newcommand vs \global\long\def? >> >> - Automatically generate styles for environments defined in imported >> documents. For example if the imported latex has a keywords environment, >> that should not suddenly become ERT in LyX. >> This should allow me to start from the conference sample file, import it >> into LyX, and obtain a first class lyx environment. >> > Both your suggestions look useful, although I'm wondering how > achievable is the 2nd one. I'd love to hear what established devels > think of this. > > Either way, I think this is a project worthy for GSoC and if you can > come up with a suitably worded project proposal feel free to place it > here: http://wiki.lyx.org/Devel/SummerOfCode2013Ideas (and let us know > on lyx-devel). This would greatly increase the chances of a student > picking it up. And if we have no student for such a project this year, > we should certainly consider it for subsequent GSoC summers. While we are talking about roundtrip - there is still the dreaded issue of MS Word (docx) roundtrip. There is again and again the discussion coming up of exporting to docx and importing docx, and (especially in the humanities as I gather from these discussions) many journals only accept doc / docx for submission. Not only the journals, but the use of LateX and LyX is not that widespread (as it should be!) in academia in general (some natural science disciplines excluded). So to make co-operation with MS Word users possible, an improved export to docx and round trip would be very useful. Also, I would assume that this feature would make LyX much more widely used. Cheers, Rainer > > Regards , > Liviu -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Idea GSoC - support for online LaTeX compiling
Hi I guess many have seen it - LyX and it's successful application for GSoC was on Slashdot [1]. That should give some publicity. The first comment raised an interesting (already discussed) feature which is missing in LyX: to enable the use of online LaTeX backends for compilation. This would have many advantages ranging from lighter installs (no LaTeX needed) over making the LyX on mobile devices easier to implement to more consistent results of compilation. Also, in the light of the proposal for collaborative editing, a common LaTeX backend would make much sense as the result would be the same for all and the pdf would not have to be shared after local generation. Cheers, Rainer Footnotes: [1] http://developers.slashdot.org/story/13/04/13/1231210/lyx-joins-the-google-summer-of-code-2013 -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug pgpVCyQhwoSqJ.pgp Description: PGP signature
Re: enable continuous spellcheck by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/03/13 22:44, Nico Williams wrote: > On Mon, Mar 25, 2013 at 3:40 PM, Scott Kostyshak wrote: >> On Mon, Mar 25, 2013 at 4:29 PM, Georg Baum >> wrote: >>> Scott Kostyshak wrote: >>> >>>> Note that this discussion is related to the discussion of the toolbar >>>> button: >>>> http://www.lyx.org/trac/ticket/8589 >>>> >>>> You describe the same use case that Liviu describes. I don't understand >>>> what the >>>> advantage of toggling continuous spellcheck is over using normal >>>> spellcheck for this >>>> workflow. If one doesn't use continuous spellcheck when writing, then it >>>> is not really >>>> "continuous" spellcheck anymore. >>> >>> I agree that toggling the button frequently while working on one document >>> does not make >>> sense. However: Assume you are drafting a project proposal and want to >>> concentrate on the >>> structure. You disable continous spell check for that. Later you switch to >>> another document >>> for fine tuning. In that situation you want continous spell check, and a >>> toolbar button >>> makes your life easier. >> >> Ah, this is a good point. Part of me thinks that in this case it should be a >> document >> setting. But that doesn't make much sense. OK, I'm sold. > > Actually, this makes me think that we need some additional features: > > - dictionary embedded in .lyx (some docs make extensive use of words that > aren't really and > shouldn't be used in other contexts) +1 - would be very useful. > > - continuous spellcheck setting should be optionally per-document +1 - this would make much sense. Actually, this goes towards having different profiles for settings - drafting, finalizing, reviewing, ... for which several settings might be different (e.g. show pictures, preview maths mode, track changes, ...). I would be a bloat of the lyx file format if all settings would be included, but to add a "settings profile" per document basis, would make much sense. Additional advantage: this profile somehow could also be used for adding optional aspects in the preamble, e.g. watermark in draft mode (like branche in the preamble. > > In the meantime, please turn continuous spellcheck on by default. It's too > late to improve my > life (I now know about the feature, so I've enabled it), but we're talking > about gaining new > users and their love. Ok - +1 Yes - and possibly open, after each update, the important changes automatically (like the default lyx document opened on new installs) Cheers, Rainer > > Nico -- > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRUWnTAAoJENvXNx4PUvmC7/wIAK4wPDYsttne37OSE9xfVdMe tT4ywmGkEB+xLwtx447UPfPKgQqKhhSkTA86wAglDRvLcTkoX6JZDVQ9vo/xHeEp /7y8CiMinLs7OESZJoKDQTRLr5vVFywcVwWQKytinZvz1e31zCSBrn1mQ/B8T/MR L2KB2Abkja595MSNw97OYnMA641JEluODWfR6lfA43OlW3uZ/4Vbjup7LHsILNRC YucDvJFkUPcAmOeGzk2JE+I1pMs9keieSmY+gfTpi/h7XoalilwCdJ68kvSs+R0Y oBxLy1lq+4/CHh1+Fz0qjhFF7tWwdxO4AV1b1e347LvGFMPHuFgGbfMT4BDQ7hY= =rL6A -END PGP SIGNATURE-
Re: enable continuous spellcheck by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/03/13 18:13, Liviu Andronic wrote: > On Sun, Mar 24, 2013 at 6:00 PM, Rainer M Krug wrote: >>> At the time there was fierce opposition from "old-school" users (including >>> several main >>> devels) to making this default. And that's OK as long as the feature is >>> easily accessible, >>> which it currently isn't. Not really. >> >> If the feature is enabled by default (i.e. new config files) but if the >> option is not present >> in an existing lyx config file, the feature is added as disabled, one can >> differentiate >> between old users (who already have an existing conf file) and new users who >> don't, where >> therefore the feature is enabled. This could make make all camps happy? >> > I sincerely doubt this. The old-school users are unhappy with LyX shipping > with continuous > spellchecking enabled by default. This covers new installs, too, so tinkering > with config files > as you suggest isn't really a solution. In principal I agree with them - it is a feature which is counterproductive to writing as it interrupts the flow of ideas / writing. But I do *not* agree that it is useless and that nobody should have it. I also would not like it to be turned on for me as an "old" user, but I would simply switch it off. > > If I understand correctly, from their perspective continuous spellchecking is > a useless feature > that shouldn't exist in the first place; but since it has gotten implemented > in LyX, the least > is to have it disabled by default. So as it stands we have a compromise. :) Well - but it does not suit "new" users, who are (more and more) used to it by using word / libre office / ... . And just enabling it in newly created config files, would not change aything for "old" users and fulfill the request from "new" users and geared towards users migrating from word et Cheers, Rainer > > Liviu > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRUBAhAAoJENvXNx4PUvmCGKEH+QGwkeQ33vhRyq7US6HP4Rwb YboaBkysv1/7eKBsq2FKjFH9kaIGA3AhgsJLo3LwsS9mcErXhsc3hQ0t0qbYEpr/ 7O4xqFmgzwlqcgl/APDeRFeqAOWN49rfmOp9zdso5CF4jEpWztoKUx7XEDrxXpf1 Ygw81F22YOtlB6P6p4hiXC9brWYSGeDxkbVJb+GJQxjot156J4o2Ueoj/1+g+sVr UuRVzvmOi1w0k0NoSkeDPtrH7qi1KrFP1YdAzHowvNsontPbJC6hKZLn3fa+ngjB RkCCVv8w5HrcvOgzq8QvLpXFngnsvaSLi1t7IXKbb6n2tyUUI91QXgvRpgTf1nw= =iBXi -END PGP SIGNATURE-
Re: enable continuous spellcheck by default?
On Saturday, March 23, 2013, Liviu Andronic wrote: > On Sat, Mar 23, 2013 at 7:00 AM, Pavel Sanda > > wrote: > > Scott Kostyshak wrote: > >> because my only argument in favor was a guess that most users prefer > >> to have it enabled. But after seeing Liviu's ticket (#8589) I talked > > > > How counted? :) > > The people who are satisfied are silent now of course. Don't remember the > > ratio but clearly remember there was oposition to make this default as > well > > when the feature was introduced. > > > At the time there was fierce opposition from "old-school" users > (including several main devels) to making this default. And that's OK > as long as the feature is easily accessible, which it currently isn't. > Not really. > > If the feature is enabled by default (i.e. new config files) but if the option is not present in an existing lyx config file, the feature is added as disabled, one can differentiate between old users (who already have an existing conf file) and new users who don't, where therefore the feature is enabled. This could make make all camps happy? Rainer > > > If discoverability is the issue new toolbar button should be added, but > > > Hence http://www.lyx.org/trac/ticket/8589 . This would make the > feature as visible as in LibO. > > Liviu > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: Creating pdf forms template
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am really looking forward to a working example - but could we please keep
this discussion on
lyx-users, as it has nothing to do with devel?
Thanks,
Rainer
On 22/03/13 14:14, John Kane wrote:
> The problem is far beyond my tiny understanding of LyX/LaTeX unfortunately.
> Have you tried a
> question on StackOverflow?
>
>
>
>
>
*From:* Alex Vergara Gil
> *To:* John Kane ; lyx-users Users
> ;
> lyx-devel@lists.lyx.org *Sent:* Thursday, March 21, 2013 5:18:53 PM
> *Subject:* Re: Creating pdf
> forms template
>
> - Original Message -
>
> *From:* John Kane <mailto:jrkrid...@yahoo.ca> *To:* Alex Vergara Gil
> <mailto:a...@cphr.edu.cu>
> ; lyx-users Users <mailto:lyx-us...@lists.lyx.org> ; lyx-devel@lists.lyx.org
> <mailto:lyx-devel@lists.lyx.org> *Sent:* Thursday, March 21, 2013 12:32 PM
> *Subject:* Re:
> Creating pdf forms template
>
> It works or at least I managed to type some text into the text box. I made a
> couple of
> changes to the text which I think makes it a bit more idiomatic in English
> (see attached. I
> hope you don't mind.
>
> I spent what seemed like forever installing the blasted insdljs.sty and it
> worked.
>
> For those having the same problem in Ubuntu I 1) created a texmf folder at
> root level
> following these directions
> http://nmv.stat.cmu.edu/2012/06/14/managing-latex-packages-manually-in-ubuntu-12-04/
>
> and then following instructions from
> http://www.latex-community.org/forum/viewtopic.php?f=5&t=8886
>
> 2. cd'd to the texmf/tex/latex/acrotex directory 3. ran sudo texhash 4 ran
> latex acrotex.ins
> Reconfigured LyX and everything ran nicely.
>
> Dear John
>
> Thanks for your reply and your idiomatic suggestions. Now I notice that it
> must be told in the
> document that for make it to work the AcroTeX package must be instaled also
> (it contains the
> insdljs.sty file), this specific package allows javascript code inside a pdf,
> so you can
> manage actions like (onselect, onkeypress, etc). It is also part of MikTeX if
> you run this on
> Windows so this should works on every platform.
>
> The problem is that if you just put
>
> {this.getField("Escuelat").readonly=false;}
>
> it works in one way, but when you uncheck the box the linked text field
> should become
> uneditable and empty. For this I expect that the code
>
> {this.getField("Escuelat").readonly=!this.getField("Escuelac").checked;
> this.getField("Escuelat").value="";}
>
> shall do the job, but it isn´t. I even made this as a function, but nothing
> happened. The rest
> of the objects work very nice but this kind of behaviour is critical for the
> next step of
> creating action buttons.
>
> Regards
>
> Alex
>
>
>
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys.
(Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRTFzeAAoJENvXNx4PUvmCz1MH+wfO2/Odl37cxml6JWsQSqIQ
nw8dUT0BX47xzjmPz/+GTHZNfi56j3rLjluCP0y/gRoH4MZMO3W8WNXf+I1XB8XG
H3SyzcXiraOzZid96wUcgVdYm5zczb8lBxq3pQYJ4t1i8/gXFkFKY70S0A7j7Izl
O3+U0BAs2g/ZBBEA/BXm5puR7tkPzXofDVxScP7I7GhM9vom1ilawfPeXBvFOQ+y
Zu4bDS3YQDRSPF3Hu9G0yuOyj/dOx/TyCbqGU2VO1ltqGGChvJ2KnIHBTnmYfzgb
DBmgbsgTNCe7MELB204hV06iPhlX2RV/dObgLJbsHutJHTT/UdLw3mFGfdPi3MQ=
=eHnK
-END PGP SIGNATURE-
Re: How to create a pdf template?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/03/13 17:00, Alex Vergara Gil wrote: > - Original Message - From: "Liviu Andronic" > Subject: Re: How > to create a pdf template? > > >> On Tue, Mar 19, 2013 at 2:34 PM, Alex Vergara Gil wrote: >>> >>> I need to create a pdf template for users to fill some boxes like a poll >>> (actually I need >>> to create a client satisfaction poll). Is there a way to do this? What is >>> the best approach >>> in this case. >>> >> I'm curious how this could be done, but wouldn't it be easier to use an >> internet service like >> SurveyMonkey or limesurvey? >> >> Liviu >> > > I live in Cuba so I have very little internet bandwith, so I prefer something > out of line, if > were possible: LyX! I know people can use adobe acrobat to do this and I have > seen many pdf in > this form, but I want to learn how to do this in LaTeX (prefereable LyX) > because I don´t want > to buy adobe´s licence (and actually I can´t because some law restrictions - > See "cuban embargo > law"). As a starting point: http://tex.stackexchange.com/questions/14842/creating-fillable-pdfs but also: http://www.ctan.org/tex-archive/info/pdf-forms-tutorial And as an example: http://martin-thoma.com/creating-pdf-forms-with-latex/ I am quite sure that you have to use ert in Lyx. Cheers, Rainer > > Regards Alex - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRSIQcAAoJENvXNx4PUvmC7ecIAKN15sMBEWfimOlxhBsX7ZS3 kWGuNIcRESWn5pdTQdG2SU/E4nXyUVT3dW3lUoyw5dEIjvMloSrsNe7lcHaOJZd3 Nryxvbx96Y8L5gbrm6c1uGEgz3Si00HEVRz8DXhNbKC2q+lvGJqLgr0vUsXmCFYy dHa52aIWHQKtcCEV1Ixqhiy4UObbMydLqF2U3ODt1PGHm2NmsBYfPaiE5jRicvz4 AA5gjC4ar2kQtKgLYnrs8akmWq8OQML/e17bML9tnUOaCAMYydpwRdyrZhmiIY5L tdwdqQ0GvbsvYM2aX8dMqFd+MT9mXc279a1T8djFgzNSHEB3Zjlyost0aw/hy3k= =+OED -END PGP SIGNATURE-
Re: Hiding "track changes" when editing #4140
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/02/13 13:13, Jrgen Spitzmller wrote: > 2013/2/26 Rainer M Krug : >> Is anything happening on the front of "hide track changes but record them" >> (http://www.lyx.org/trac/ticket/4140) ? > > No(thing that I'm aware of). Pity Cheers, Rainer > > Jrgen > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLbb5AAoJENvXNx4PUvmC7fMIANOpEk71/TLn+vRvU0Zhhow1 nE7cq8nfYk6U2RAqgjpb3PJQMGusJriThLSEIx23anEu/uLlw13TWSzbzL3qq49G rSPaXqtGR+ZpIaA79fVEVY60CtKBpLag4B8kybDrtCKDNb0etFqQ+WKTCoCcVPtq mu+J5cbBLlvviQ0twDSSrbIPDG7StbDhFghxqmr2eK94rSFmgZ+Fh1XYmk0CIGwC mhSwCYf0lSYuNexJ8lTGRr1z6tFhDNs35Dn93w7fNhc1haLEAZVEHFnhm9SFkUyv PoeoLUF/buIGSJFTXzPzEOUZig7Pp+XK3fBmGQuhmMx4+KQRDxt5AHFbG1sR+Cs= =V/Rb -END PGP SIGNATURE-
Hiding "track changes" when editing #4140
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Is anything happening on the front of "hide track changes but record them" (http://www.lyx.org/trac/ticket/4140) ? I am in the process of revising a paper and I assume my co-autthors would like to have track changes, but it is nearly impossible to work in certain sections where there are many changes. Cheers, Rainer - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLIztAAoJENvXNx4PUvmC0rQH/0FeHVorNLInNmIy/QEPfDPv HCk2sXYZ9jvffZZN387SOx1P3oWVjuLkkYiOCztPOHQJueriVDWWqqYaLJoTQMII YZNheej1Zlldgoq3jol3s0DtYhAlqvSoXl2pXIY3Yf6jgT2QLnikyAncPsI8yY4h 6pZLrTndS66aNu3XtcpyM8SvaF6HxYAnVc2ZueMAb4cayxF6VZ2jaJC64zOV9Gce G3fDQ9Ss1f106ARfNxmHuGIuM7ZsJhUObJhp1evlHrjMrwehA7f4mPUmxGf8Km9Q 0T/Ge/ZB9Zq5lxQ1y8oov4Kod8B49ZBjVMqHZnLiT/u/04QgorcibPUlRRW9zcs= =O6TX -END PGP SIGNATURE-
Re: an idea to improve lyx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/12 18:40, Liviu Andronic wrote: > On Thu, Dec 6, 2012 at 6:31 PM, Richard Heck wrote: What do you think of that? >>> >>> It would be rather frustrating to not be able to type a backslash without >>> having to quit >>> the autocompletion or to suddenly end up writing the title. >> >> I wouldn't want to do this by default, but I can see why it would be useful >> for some people. >> > Maybe not bound to `\', but to some 'ctrl + \' or not bound to What I just, following this thread, is to bind Ctrl+\ to ert-insert - so I can easily (and intuitively!) go into "LaTeX mode". auto-completion for LaTeX in the ERT box will be tricky I guess, due to all the packages which can be loaded in the pramble - but nice. Thanks for this idea, Rainer > anything by default, such autocompletion functionality could prove rather > handy to hardcore > LaTeX users. UI-wise I imagine that it could take the form of the > auto-completion that we > currently have in Math, or the toolbar approach of 'alt + x'. > > Liviu > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlDBuewACgkQoYgNqgF2egpM2gCfRzesQZMJwHFZxHaqKxkywGQB WKQAniGJSEfW1Go/GEB1+8qHLmNaCBOJ =7iFN -END PGP SIGNATURE-
Re: #8353: Lyx spellcheck (dialog) crushes on Mac OSX Lion 10.8.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/12 10:50, Stephan Witt wrote: > Am 26.09.2012 um 10:46 schrieb Tomasz Koziara : > >>> I cannot see how the crash is related to spell checker. It looks like a >>> crash in an action >>> after double click in work area. >> >> The only double click I can think of was on the suggested word in the list >> inside of the >> spell checked dialog. That is interesting - just Yesterday, I had several crashes when doing spell checks - I tried enchant and aspell, and on both it crashed. I am using 2.0.4 on Ubuntu Precise Pangolin. If you need more info, please let me know. Cheers, Rainer > > So, I'll try that. Thanks. > > Stephan > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBi2dMACgkQoYgNqgF2egoj/QCgivS6pW3uVeSEuxWARm5ZKQwZ llMAnAhztZrug5SXvLhfL/VtwDWUbqSe =rAOd -END PGP SIGNATURE-
Re: Closing views versus closing buffers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/09/12 11:41, Jürgen Spitzmüller wrote: > Rainer M Krug wrote: >> OK - this makes sense, but why not close the master if one is working only >> in the child >> document? > > Because this would close the master and all its children. And I want to keep > the master buffer > active (to use master-buffer-view, for instance). Thanks for the clarification, Rainer > > Jürgen > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBW938ACgkQoYgNqgF2egq8AACdFjd20woZQU7QIS6787D7QVsD ZfQAn39BmtHO/cABjFRRlNAejp/bjz9e =QpKF -END PGP SIGNATURE-
Re: Closing views versus closing buffers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/09/12 10:10, Jürgen Spitzmüller wrote: > Rainer M Krug wrote: >> But anyway: is there a real use-case or need for the hide function? > > Yes: You work with a multi-part document, and you want to hide the master. OK - this makes sense, but why not close the master if one is working only in the child document? Rainer > > Jürgen > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBW614ACgkQoYgNqgF2egpbPACfWBQdWt4Jj04yW2vrWEsk4fGr 4VsAn3KrSrP4MOCk3WXAIdGJLqGvpXIF =vJ46 -END PGP SIGNATURE-
Re: Closing views versus closing buffers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/09/12 15:05, Pavel Sanda wrote: > Tommaso Cucinotta wrote: >> Also, I just noticed that the "Close Tab" action available when >> right-clicking on a tab name, >> actually closes the buffer, along with all tabs in any view possibly >> associated to it. This >> behavior seems also quite wrong, in my opinion. > > You are right, the current function it should be named "Close buffer" then. > Pavel > I would suggest, that all actions on right-click on the tab should only affect the tab, and not the buffer - this would make logical sense (as there is a "Documents" menu), and solve inconsistencies and clarify things. Another entry which could then be added, would be "open new tab in new LyX window". The "close" in the tab would then only close the tab and, if it would be the last tab, ask if it should also close the document or hide it, ui.e. leave it loaded but close the last tab. Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBW2YkACgkQoYgNqgF2egouYgCgiZUR8mdBnptx6l8qFbfSlqEc e8wAnjmDXlIfCANFqrI1P2RqRYigdEk/ =Tf+v -END PGP SIGNATURE-
Re: Closing views versus closing buffers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/09/12 14:55, Pavel Sanda wrote: > Tommaso Cucinotta wrote: >> On 13/09/12 01:07, Pavel Sanda wrote: >>> Richard Heck wrote: > Shouldn't we close the view only, >>> I thought thats why we have "hide" function distinguished from close. >> >> The problem with hiding is that the buffer is not automatically closed after >> the last view >> has been hidden. > > This is not problem but feature. By hiding you mean hiding, not closing. Actually - why is there a "hiding" function? Opening a document is fast and if one needs the document, it should stay open. Also, I would not call it "hiding the buffer or document", but rather "hiding the tab" or, better even, a kind of minimize, where the width of the tab is set to a very small value, but is still visible. But anyway: is there a real use-case or need for the hide function? Cheers, Rainer > > Pavel > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBW2KQACgkQoYgNqgF2egqA4ACfWIXN/V/v9jGD+Z3T1CZ+lb4e ZY4AnjjlxKwPcZUXUltJ0EwNTMpAdLiO =NdPO -END PGP SIGNATURE-
Re: Closing views versus closing buffers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/09/12 12:26, Tommaso Cucinotta wrote: > On 13/09/12 10:29, Rainer M Krug wrote: > >> What about a popup box, asking: >> >> - Do you want to close All windows / views of this document >> or only this >> one? >> >> All / Only This / Cancel >> >> [ ] Do this from now on automatically - >> >> By doing this (if more then one window of a document exists), the user could >> costomise the >> behaviour. > > yes, that could be an option. As a basis, I think LyX should have all the > LFUNs to handle > these cases, then the GUI behaviour may also be customised via the .bind > files. >> Also: There should be a command, below the close, >> >> Close Document Window >> >> which is closing only the one window. > > or, perhaps, "Close Document View" or "Close Document Tab", because the > "Window" word already > refers to the whole LyX Window, as in File->"New Window" or File->"Close > Window". > > On a related note, I find it weird as well that, once you do File->"New > Window", the new LyX > window is empty, resembling a whole new LyX instance. Actually, the > View->hidden menu of it > would still allow to open the same files that are already open in the other > window. However, > the average user would think such a function creates a new LyX instance, but > such an action is > often accessible from the general OS GUI or Window Manager (e.g., click again > on the program > icon -- even though in recent distros with Unity and the like that tends to > change). > > A more natural behavior (for me) would be that the new LyX window shows the > same buffer that > was shown in the other window from where the command was triggered. Weather > or not the new > window should have the same tabs, split views, etc., I don't know. But, at > least what I think > is a common use-case, is the one of when you want a second view on the same > buffer you're > editing, in a completely different LyX window, e.g., to exploit the window > manager capabilities > on that window (e.g., push to another monitor or whatever). Agreed - that would make it clear, that it is simply "a new niew of the same document in the same LyX instance" and not a new LyX instance. Cheers, Rainer > > Bye, > > T. > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBW1/wACgkQoYgNqgF2egrWcQCfUZQ9ECHqDbWuOJe2pPRB7MiU VhoAmwSeLS5TIunLdBvxxrmBFm45tX6L =OomI -END PGP SIGNATURE-
Re: Usage of \begin{centering} in floats
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/09/12 11:51, Liviu Andronic wrote: > On Thu, Sep 13, 2012 at 11:32 AM, Rainer M Krug wrote: >>> Instead, I vote for an alternative GUI method to center graphics (or other >>> content) with >>> \centering. I would also welcome a generic setting to have graphics in >>> figure floats >>> centered by default (If you browse the list postings of the past 10 or so >>> years, you will >>> find that this is a long standing request not only by me). >> >> In principle I agree, but changing a default value means asking for trouble. >> Instead, an >> additional option for floats "centre by default" which is disabled in the >> default, might be >> the way to go. >> > Yup, this sounds reasonable to me, too. > > Perhaps a more complete solution would be to: - rename 'Settings > Float > placement' to > 'Settings > Floats' - in it replicate the UI for the current "float > placement" options and > have a 'Use default alignment' checkbox accompanied by 'Advanced alignment > options' label and > the alignment radio buttons in 'Paragraph settings' - replicate the UI above > in Float > > Settings - Float alignment settings would be respected only if the paragraph > settings are set > to 'default' > > But I'm not sure if this proposal would mean too much cluttering of the UI. > Perhaps a single > option in 'Settings > Floats' and 'Float > Settings' along the lines of: 'Use > centered > paragraph alignment by default' I like your suggestion, and don't think it would be to much clutter, if two tabs would be used. Please see the tracker below. > > is indeed the way to go. Either way, someone should file this on the tracker. Done. http://www.lyx.org/trac/ticket/8337 Please complete if I have missed something. Cheers, Rainer > > Liviu > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBRsfIACgkQoYgNqgF2egpBDwCdGyfZBGOYdHhLtQAtfvqnrz4I b8EAn0NGGkyWsUPQksl5Ca6iV61qe7Gm =uKQ3 -END PGP SIGNATURE-
Re: Usage of \begin{centering} in floats
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/09/12 10:25, Guenter Milde wrote:
> On 2012-09-12, Rainer M Krug wrote:
>
>> Hi
>
>> I am by no means a LaTeX expert and only was told
>> (http://tex.stackexchange.com/questions/71280/best-way-to-centre-figure-in-float
>> and also
>> http://tex.stackexchange.com/questions/2651/should-i-use-center-or-centering-for-figures-and-tables)
>>
>>
that
>
>> \begin{centering}\includegraphics{whatever} \end{centering}
>
>> should not be used and is actually wrong and
>
>> \centering\includegraphics{whatever}
>
>> should be used instead. Now I am wondering: is there a reason, why LyX uses
>> \begin{centering}
>> in floats and not \centering, which apparently is the correct way?
>
> The difference is not whether the centering happens in a float or elsewhere.
> You could also put
> 3 paragraphs of text like
>
> A leading text.
>
> A centered paragraph.
>
> A trailing text.
>
> Figure 3: example of "text figure"
>
> in a figure float.
OK - so \begin{centering} is more robust here, but from a LaTeX point of view
wrong - correct?
>
>> Should this probably be changed?
>
> Instead, I vote for an alternative GUI method to center graphics (or other
> content) with
> \centering. I would also welcome a generic setting to have graphics in figure
> floats centered
> by default (If you browse the list postings of the past 10 or so years, you
> will find that this
> is a long standing request not only by me).
In principle I agree, but changing a default value means asking for trouble.
Instead, an additional option for floats "centre by default" which is disabled
in the default,
might be the way to go.
Cheers,
Rainer
>
> Günter
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBRqDIACgkQoYgNqgF2egp/TQCffBXXddeMZGNW0D786lquI47+
K2IAn1YooO6qJMF+CKe1ARqtjWR+ddLe
=KmxF
-END PGP SIGNATURE-
Re: Closing views versus closing buffers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/09/12 10:32, Jean-Marc Lasgouttes wrote: > Le 13/09/2012 02:07, Pavel Sanda a écrit : >> Richard Heck wrote: Shouldn't we close the view only, What about a popup box, asking: - Do you want to close All windows / views of this document or only this one? All / Only This / Cancel [ ] Do this from now on automatically - By doing this (if more then one window of a document exists), the user could costomise the behaviour. Also: There should be a command, below the close, Close Document Window which is closing only the one window. I guess that the confusion comes from the fact, that LyX has no "Windows" menu, like LibreOffice (Might be an option to add one?) >> >> I thought thats why we have "hide" function distinguished from close. I must admit, that one is quite hidden - and it does not seem to close the view, but only hides it - - it is under the "hidden" submenu under "View". > > I think this view vs buffer stuff is becoming too complicated to be really > useful. Well - I think the problem is that everything is under the same menu. > > Example: on a mac (use views instead of tabs), the list of open documents in > View buffer is > useless. > > JMarc > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBRp2QACgkQoYgNqgF2egpalQCfcnInIF8QmdXax33XPo5LGQA9 tHEAniWE+yswwR8wWFR3VDzIzhAHO4jA =LGDM -END PGP SIGNATURE-
Usage of \begin{centering} in floats
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
I am by no means a LaTeX expert and only was told
(http://tex.stackexchange.com/questions/71280/best-way-to-centre-figure-in-float
and also
http://tex.stackexchange.com/questions/2651/should-i-use-center-or-centering-for-figures-and-tables)
that
\begin{centering}\includegraphics{whatever}
\end{centering}
should not be used and is actually wrong and
\centering\includegraphics{whatever}
should be used instead. Now I am wondering: is there a reason, why LyX uses
\begin{centering} in
floats and not \centering, which apparently is the correct way?
Should this probably be changed?
Cheers,
Rainer
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys.
(Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBQp3AACgkQoYgNqgF2egoZwgCePqc1GRgBq5uHxIAFKbL6M8+H
CDgAnjS+W6oKwKffafR2SSCy4uzsqVDY
=KZtm
-END PGP SIGNATURE-
Re: www.lyx.org is down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/12 18:19, Richard Heck wrote: > On 09/05/2012 11:44 AM, Rainer M Krug wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 05/09/12 16:18, Richard Heck wrote: >>> On 09/05/2012 01:31 AM, Scott Kostyshak wrote: >>>> On Tue, Sep 4, 2012 at 10:31 PM, Richard Heck wrote: >>>>> On 09/04/2012 09:48 PM, Scott Kostyshak wrote: >>>>>> Is notifying that lyx.org is down useful? >>>>>> >>>>> Yes, it signals me to try to fix it. I'll see what I can do. >>>> OK. >>> Seems magically to have fixed itself. >> Well - I get when trying to access http://www.lyx.org/ : >> >> >> Forbidden >> >> You don't have permission to access / on this server. Apache/2.2.15 (CentOS) >> Server at >> www.lyx.org Port 80 > Ahh, we rebooted. Fixed again. Working - thanks. Rainer > > rh > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBIVO4ACgkQoYgNqgF2egq66ACfTreYxSXHzGI2pOLdpvmXqVP6 e5sAnA8E+0BX9lTp0e7iFmB3wFwho8Sc =vAak -END PGP SIGNATURE-
Re: www.lyx.org is down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/12 16:18, Richard Heck wrote: > On 09/05/2012 01:31 AM, Scott Kostyshak wrote: >> On Tue, Sep 4, 2012 at 10:31 PM, Richard Heck wrote: >>> On 09/04/2012 09:48 PM, Scott Kostyshak wrote: Is notifying that lyx.org is down useful? >>> Yes, it signals me to try to fix it. I'll see what I can do. >> OK. > Seems magically to have fixed itself. Well - I get when trying to access http://www.lyx.org/ : Forbidden You don't have permission to access / on this server. Apache/2.2.15 (CentOS) Server at www.lyx.org Port 80 Cheers, Rainer > > rh > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBHc3AACgkQoYgNqgF2egpJrgCgipbaOc6rdugJDPV/3fIV/xDf TUsAnR0spuREZHKciOXGZwDkcqHmbfLT =2Qq3 -END PGP SIGNATURE-
Re: LyX functions for bibliography managers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/06/12 16:46, Richard Heck wrote: > On 06/14/2012 10:25 AM, Rainer M Krug wrote: >>>> 2) the possibility to include the .bbl file, generated when compiling the >>>> LaTeX, in the >>>> export to LaTeX. This is required when submitting articles to journals and >>>> this feature >>>> would make life much easier and reduce the manual editing necessary after >>>> export to >>>> LaTeX. >>>> >>> The include_bib.py script will do this already. >> Didn't know about that one - maybe put it into one of the menues or as an >> option in the >> LyXArchive export? >> > I'm not sure how much trouble it is to add it to the Archive business. The > reason it's not in > the menu is described in the bug that led to it. There are issues with > sectioned > bibliographies, etc. Makes sense - so just leave it for the time being as it is. Cheers, Rainer > > Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG > with Mozilla - http://enigmail.mozdev.org/ > iEYEARECAAYFAk/Z9HMACgkQoYgNqgF2egqgjgCffD4Orap1S69Iyiu76nwaTCQq > js4An2/hdnbeJx+vXx2/c9YUc5g3AqPc =D66C -END PGP SIGNATURE- > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/aItIACgkQoYgNqgF2egrNqgCeKZba7OxJpHYqEc+q8e5EezGz X1UAnii0Djvzbf6inJJeNj3pTAaEBMqD =hIIZ -END PGP SIGNATURE-
Re: LyX functions for bibliography managers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/06/12 16:10, Richard Heck wrote: > On 06/13/2012 07:54 AM, Rainer M Krug wrote: >> While we are at that subject what is missing in the citation management, I >> would like to see >> two things: 1) the possibility to create a local .bib file (in the directory >> of the .lyx >> file) which contains only the references used. This would make co-operation >> between authors >> much easier. If this file could be embedded in the .lyx file, this would be >> brilliant, >> although this is not necessary, as other external files also exist. >> > I'm not sure exactly how you want this to work, but it can easily enough be > done with aux2bib. > The downside to this method, to my mind, is that it's one-off: Once you've > created this custom > bib file, you've lost the ability to cite anything from your other bib file. > So I tend to do > this only at the end, or near it. True - so a functionality, where LyX first looks in its local lyx.bib file (embeded or in LyxArchive) and then in the other bib file mentioned in the bibliography settings, and *ignores with warning* non existing external .bib files. In such a way, I could push all cittations in the lyx.bib file which I can give together with the LyX file to my co-author. They can then edit the LyX file and also add citations from their local .bib files which are mentioned in the LyX file. > >> 2) the possibility to include the .bbl file, generated when compiling the >> LaTeX, in the >> export to LaTeX. This is required when submitting articles to journals and >> this feature would >> make life much easier and reduce the manual editing necessary after export >> to LaTeX. >> > The include_bib.py script will do this already. Didn't know about that one - maybe put it into one of the menues or as an option in the LyXArchive export? Rainer > > Richard > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Z9HMACgkQoYgNqgF2egqgjgCffD4Orap1S69Iyiu76nwaTCQq js4An2/hdnbeJx+vXx2/c9YUc5g3AqPc =D66C -END PGP SIGNATURE-
Re: LyX functions for Zotero
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/06/12 11:43, Benjamin Piwowarski wrote: >> >> >>> >>> - Add a function "bibtex-entry-get " that retrieves a BibTeX entry >>> given its key >>> >>> - Add a function "bibtex-entry-put " that finds the next BibTeX >>> inset and either - >>> Update the entry in a LyX managed BibTeX file (if it exists within the >>> bibtex inset) - Adds >>> the entry to the first available LyX managed BibTeX file if the key does >>> not exist; >>> optionally, it can create a new managed BibTeX file (same folder, same name >>> but with a >>> "_XX.bib" suffix where XX can be used to distinguish several local >>> databases in order to >>> deal with sectioned bibliographies). >>> >> >> There are two options now: 1) integrate the above mentioned into LyX >> citation system, i.e. >> that the references are added automatically when inserted in the document >> into the local bib >> file (let's call it for arguments sake lyx.bib). This would be the cleanest >> option, as this >> lyx.bib would be the one used by LaTeX when compiling. > I would prefer this option. Anyways, the user can have several database in a > bibtex inset, and > the order gives the preference to either the local or the global. Me to - much cleaner. > >> >> 2) Have one button which generates the lyx.bib document wide. This would >> have the advantage >> that users can decide if they want to use lyx.bib or their central bib file. >> Problem could be >> when the lyx.bib is not up to date - could one use both bib files? maybe >> change the key in >> the lyx.bib to originalkey_lyx ? >> >> Yes - adding from user bib to lyx.bib and updateing *selected* entries in >> lyx.b ib are >> useful. >> > I think this is solved by the order given to the databases. > OK - perfect. - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ZzNsACgkQoYgNqgF2egpT1ACfUctcUSnOHh6LkYZtmk6N83hc FjwAoIONo4Vbn3/x9E3rRwucqLJRZGv2 =BeX2 -END PGP SIGNATURE-
Re: LyX functions for Zotero
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/06/12 10:47, Benjamin Piwowarski wrote: >> >>> I guess what I was proposing on the mailing list earlier corresponds to this >>> "bi-directional communication" between a bibliography manager and LyX: two >>> LyX functions >>> (to retrieve and store a BibTeX record), that would automatically find the >>> appropriate >>> BibTeX database and update it. >> >> I would oppose the idea of editing the original bib file from LyX - that one >> is the domain >> of the bibliography manager (JabRef, mendeley, ...) and I would not go >> there, as e.g. >> mendeley does only export to the bib file, and not re-import changes. So >> this could eb a step >> towards unwanted complications. > > Editing would be restricted to adding or removing BibTeX entries. But I agree > that having > managers automatically exporting might get LyX into trouble. What I would > propose is LyX > "flavored" bibtex files (see below). > >> >> If you are referring to editing a *local* bib file of LyX, which contains >> all added >> references and is the bib file used by LaTeX when compiling, then this is >> OK, as it does *not >> touch* the original .bib file. [...] Embedding in the LyX file or embedding >> in the LaTeX >> file? these are two completely different approaches, as embedding in the LyX >> file would mean >> that when opening the LyX file, the embedded .bib file(s) is (are) extracted >> to the tmp >> direcrory and available as .bib for LaTeX. > > I think embedding into the LyX file would be the best solution given the > above. We want to be > sure that the file is local and not exported automatically by a manager > (although this could > be checked with the file headers which in general state whether a file is > generated or not). > Or, reversely, LyX could produce a "header" that says that the file can be > modified (I would > rather go this way). Thinking about it, that is secondary, and as the graphs are also external files, it shouldn't be a problem to have the local bib files also as external files. They should be included in the LyX archive nevertheless. > >> >>> >>> Pros: - Easy to maintain since we can store separately the entries - No >>> concurrent access >>> to the BibTeX entries - No need to handle external BibTeX files (errors, >>> etc.) >>> >>> Cons: - cannot be edited easily with a BibTeX editor - >> >> Assuming embeding in LyX: one could edit theone in the tmp directory, which >> would then be >> updated when saving. > Yes, but then if the user forgets to save the file then it becomes a bit more > complicated. True - one can deal with embedding later. > >> >>> in case of sectioning (bibtopic), we need to define multiple embedded >>> databases - >> >> Should't be a problem in the LyX file. >> >>> introduces an incompatibility in file format with previous LyX versions >> >> Not necessarily - I think one could deal with this. > OK, but how would you deal with this? I was thinking of adding a list of > local BibTeX > databases within the document preferences, but I am not sure this is the best > way to deal with > this. > > > All in all, I think that the best option would be to have local BibTeX file > (i.e. in the same > folder as LyX) which are marked (with a header, a special extension like > ".lyxbib"?) so that > LyX know it can update the file. That way, compatibility is maintained (after > all, this is just > a bibtex file), we avoid the problems of bib manager generated files. I think normal bib files, but they could be named with the same filename as the .lyx file, but with the extension .bib. If there are more needed, they could be named filename.1.bib, filename.2.bib, ... Cheers, Rainer > > I was thinking of taking the BibTeX parsing code and to modify it so that it > can update a file > (by replacing the entry if it matches the key). > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Zpw0ACgkQoYgNqgF2egp52wCeL6wskcCUdIFYJ6fFlPusNo12 5KUAn3eaICQk5Y1EPQq0Zz4/ri+m+H47 =nXn0 -END PGP SIGNATURE-
Re: LyX functions for Zotero
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/06/12 09:14, Benjamin Piwowarski wrote:
> I guess what I was proposing on the mailing list earlier corresponds to this
> "bi-directional
> communication" between a bibliography manager and LyX: two LyX functions (to
> retrieve and store
> a BibTeX record), that would automatically find the appropriate BibTeX
> database and update it.
I would oppose the idea of editing the original bib file from LyX - that one is
the domain of the
bibliography manager (JabRef, mendeley, ...) and I would not go there, as e.g.
mendeley does only
export to the bib file, and not re-import changes. So this could eb a step
towards unwanted
complications.
If you are referring to editing a *local* bib file of LyX, which contains all
added references and
is the bib file used by LaTeX when compiling, then this is OK, as it does *not
touch* the original
.bib file.
>
> The main difficulty is to define how to store the entries - i.e. whether it
> is better to embed
> it into LyX;
>
> Embedding would be:
I guess you are referring to my earlier post:
Embedding in the LyX file or embedding in the LaTeX file? these are two
completely different
approaches, as embedding in the LyX file would mean that when opening the LyX
file, the embedded
.bib file(s) is (are) extracted to the tmp direcrory and available as .bib for
LaTeX.
>
> Pros: - Easy to maintain since we can store separately the entries - No
> concurrent access to
> the BibTeX entries - No need to handle external BibTeX files (errors, etc.)
>
> Cons: - cannot be edited easily with a BibTeX editor -
Assuming embeding in LyX: one could edit theone in the tmp directory, which
would then be updated
when saving.
> in case of sectioning (bibtopic), we need to define multiple embedded
> databases -
Should't be a problem in the LyX file.
> introduces an incompatibility in file format with previous LyX versions
Not necessarily - I think one could deal with this.
Cheers,
Rainer
>
> Benjamin
>
> On Jun 13, 2012, at 15:15 , Jack Tanner wrote:R
>
>> So long as we're talking about bibliography workflow: could LyX integrate
>> better with
>> Zotero?
>>
>> Zotero is historically a Firefox add-on that has expanded to other
>> platforms. It can collect
>> references, files that go with those references, and it can plug in to Word
>> and other word
>> processors to manage citations in a document.
>>
>> With LyX, the best Zotero integration today is via the LyZ Firefox add-on.
>> You can select a
>> reference in Zotero, and then click on "send to LyX". LyZ will place the
>> reference in a bib
>> file and send it to LyX via pipe. But what if you change the reference in
>> Zotero that is
>> already in the bib file? Then LyZ needs to find it in the bib file, which is
>> not robust. And
>> if you edit the bib file manually, then a later export from Zotero will
>> overwrite your
>> changes. Also, Zotero may use a different encoding than the bib file, so
>> non-ASCII characters
>> may be broken. You can escape characters in Zotero for LaTeX with {}, but
>> that breaks
>> citations of those words in other word processors.
>>
>> What would be useful is bi-directional communication between LyX and Zotero
>> so that
>> references can be changed on either end and so that there's no intermediate
>> bib format.
>> Zotero has plug-ins for Word and LibreOffice. Perhaps LyX could have an API
>> that is similar
>> to what these plug-ins require, and the Zotero folks could be convinced to
>> extend their
>> plug-ins to cover LyX. Some more info
>> http://www.zotero.org/support/word_processor_plugin_installation_for_zotero_2.1
>>
>
> -- Benjamin Piwowarski LIP6/CNRS, University Pierre et Marie Curie (UPMC)
> case 169 – 4, Place
> de Jussieu – 75252 Paris cedex 05 – France benja...@bpiwowar.net
> http://www.bpiwowar.net/
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/ZoeQACgkQoYgNqgF2egonFwCcC6YEW9htqRRK3tyge/hSj/s8
PCoAn2IJrCx4QL2b4foRsRM+IFLsnFfT
=RzJ8
-END PGP SIGNATURE-
Re: LyX functions for bibliography managers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/06/12 13:24, Jürgen Spitzmüller wrote: > 2012/6/13 Benjamin Piwowarski : >> I agree to some extent: citation managers would still be in charge of the >> edition of the >> BibTeX entries, but these functions would allow them to communicate directly >> with LyX in >> order to easily add new entries to a paper. For example, in Jabref or >> Bibdesk, you would push >> the "Send to LyX" button that would not only insert the citation but also >> add the BibTeX >> entry if not present. I agree this is already doable (with the functions of >> the patch), but >> this would simplify the work of developers of bibliography managers and >> hence allow a better >> LyX support. > > What I personally miss is the possibility to add a citation in a specific > (e.g. natbib) style, > maybe even with pre and post field. I find myself often inserting a citation > via an external > manager and then have to use LyX's dialog anyway to set the style and add the > page numbers. The > citation-insert function would need to be enhanced to provide this. And maybe > we would need a > similar function as yours that passes the current style choices to the > manager. While we are at that subject what is missing in the citation management, I would like to see two things: 1) the possibility to create a local .bib file (in the directory of the .lyx file) which contains only the references used. This would make co-operation between authors much easier. If this file could be embedded in the .lyx file, this would be brilliant, although this is not necessary, as other external files also exist. 2) the possibility to include the .bbl file, generated when compiling the LaTeX, in the export to LaTeX. This is required when submitting articles to journals and this feature would make life much easier and reduce the manual editing necessary after export to LaTeX. I agree that the management of the bib file itself should be left to JabRef et al. Cheers, Rainer > > Jürgen > >> Benjamin > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Yf2QACgkQoYgNqgF2egqylQCdF03yLlv0DGZCqzw9Kruc9dEK 75sAnRL035DuFM0mC6Ygsy0trUOxJs6t =zMNI -END PGP SIGNATURE-
Re: word2lyx (Word to LyX Translator): Status Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/03/12 10:03, Alex Fernandez wrote: > Hi, > > On Thu, Mar 8, 2012 at 4:36 PM, Rob Oakes wrote: >> I'm sympathetic to this point. I understand that having a way to go from one >> to the other is >> important. I've deliberately avoided creating an export to Word option, >> though, because it >> would essentially require that I recode large portions of LyX in Python. I'm >> resistant to >> doing that because it's a a lot of extra code to maintain. There are already >> two >> implementations of LyX document parsing libraries: eLyXer and that found in >> LyX itself. >> Adding a third and trying to keep it in some sort of synchronization would >> be a huge pain. >> I'm looking into using eLyXer for Word conversion from LyX, but that is >> lesser priority than >> making Word import work correctly. (At least at the moment.) If there is >> someone (maybe Alex >> or another eLyXer dev) who would be interest in collaborating and handling >> the export part, >> I'd be happy to coordinate with them so that we're able to round-trip. > > That would be great. Unfortunately eLyXer is pretty much a solo project at > the moment, and I > don't have the time (or even the inclination) to do the job. But it might be > a great project to > have someone else started on the eLyXer codebase, and I would provide all the > assistance needed > to learn their way around. Interested parties are encouraged to contact me if > you feel that you > might want to tackle this project, always with Rob's coordination. An option for the Google summer of code? > > Alex. - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ZyLUACgkQoYgNqgF2egomlwCfW5I0PYdKlacLfK1s07UZjdYm iZcAn1s3HiFsPpYNS3ZQaJL11rx49hXf =8p3Z -END PGP SIGNATURE-
Re: word2lyx (Word to LyX Translator): Status Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/12 16:36, Rob Oakes wrote: > > On Mar 8, 2012, at 2:21 AM, Rainer M Krug wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> I would love to agree, but round-trip is what is needed most of the time. An >> import word2lyx >> is perfect, but in most cases only half the story. I would use it >> extensively if the round >> trip is possible. Obviously, we can not deal with the word-editing side >> (whatever program is >> used for that). > > I'm sympathetic to this point. I understand that having a way to go from one > to the other is > important. I've deliberately avoided creating an export to Word option, > though, because it > would essentially require that I recode large portions of LyX in Python. I'm > resistant to doing > that because it's a a lot of extra code to maintain. There are already two > implementations of > LyX document parsing libraries: eLyXer and that found in LyX itself. Adding a > third and trying > to keep it in some sort of synchronization would be a huge pain. I'm looking > into using eLyXer > for Word conversion from LyX, but that is lesser priority than making Word > import work > correctly. (At least at the moment.) If there is someone (maybe Alex or > another eLyXer dev) who > would be interest in collaborating and handling the export part, I'd be happy > to coordinate > with them so that we're able to round-trip. That makes perfect sense - to re-invent the wheel is not very useful. > >>> People will take this as a promise and complain that it does not work well >>> enough. >> >> Well - one could state that the round-trip works for MS word version abcd, >> and other >> versions can / will / might cause problems which are not in our hands. > > I've already taken that position. I'm willing to work with Word versions 2007 > and 2010, and > only files saved in docx. I'm not going to even try and parse doc binary > files. word2lyx is > about a 1000 lines of code. The doc parsing libraries I've looked at are > easily 10 times that > long. Python has excellent libraries for parsing XML that do nearly all the > heavy lifting. I > would have to write my own parsing library for doc. > >>> The difference of structure between word and lyx are too important to be >>> able to work in a >>> word<->LyX collaboration IMO. >> >> There are obviously basic difference in how LyX and word are viewing >> documents, and these >> lead to principal differences how the files are saved. >> >> But I am thinking that if one can import a docx file into LyX, one should be >> able to do the >> reverse. And one should be able to define a robust subset of features which >> are maintained >> when doing a round-trip. In the same way that certain features are not >> converted in word2lyx, >> lyx2word would also only support a subset of features which are exported. >> But if these >> subsets include the most important features used in the editing process on >> both sides, a >> round trip should be possible. > > I agree that it is possible, but there's a lot of code needed to make it work > correctly. It's > also a larger problem set that I want to right now. Once I've got the Word > import working, > including track changes and notes (and probably maths, too), I'll be more > willing to come back > and take a look at it. That is perfectly fine with me - it is better to have one working word2lyx than a not really working set of word2lyx and lyx2word. > > But as I said earlier, if there's someone who would like to jump on board and > work with Word > export (lyx2word), I'll be happy to coordinate and work with them, too. Cheers, Rainer > > Cheers, > > Rob - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Zw+EACgkQoYgNqgF2egrfgwCcDU8gCd8ouBi6vTmSB/Vi7mjB JfwAnRG6RCMLXXSwbtVo1fEmBY+ONq/q =v+Qw -END PGP SIGNATURE-
Re: google summer of code is starting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/02/12 19:45, stefano franchi wrote: > On Sat, Feb 11, 2012 at 6:49 PM, Tommaso Cucinotta > wrote: >> Il 05/02/2012 20:48, Vincent van Ravesteijn ha scritto: >> >>> Op 4-2-2012 21:04, Xu Wang schreef: >>>> >>>> I remember there was an effort to participate last year but >>>> it didn't work out. Just thought I would share this that >>>> gives the timeline for this year: >>>> >>>> >>>> http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html >>>> >>>> >>>> Xu >>> >>> >>> Thank you for the reminder. The deadline this year is March 9. >>> I put up a new wiki page: >>> >>> http://wiki.lyx.org/Devel/SummerOfCode2012Ideas >>> >>> Let's put out a call for projects and mentors ? >> >> >> Projects: 1) re-implementation of the Advanced Find based on >> directly matching the document and find buffers 2) distributed >> collaborative real-time editing >> > > I would add a lower-impact (I guess) variation of 2: > > 3) Git integration More general: 3.a) make the VC backend aware of all files needed to compile the document, i.e. include all files which are copied to the tmp folder during a compilation of the document into the checkin. 3.b) add support for git Rainer > > Cheers, > > Stefano > > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk86HFYACgkQoYgNqgF2egpfOACfRMiAA7EKWma+NbbGTE50vOQK c0gAn03WUU4wRdBgkB1bBAg9B/DJSV0B =hi9V -END PGP SIGNATURE-
Re: Import into LyX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/12 19:27, Liviu Andronic wrote: > On Thu, Feb 2, 2012 at 6:50 PM, Rob Oakes > wrote: >> very nice. Hearing your opinions about doc support (versus only >> docx support) would also be very helpful. >> > If .docx-only support simplifies your task and helps ensure that > your tool would support a good deal of functionality, then I'm all > for it. Support for .doc can be worked around, not least by > resaving the document in LibreOffice. +1 Rainer > > Liviu - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8q23YACgkQoYgNqgF2egoqZgCeODGYVqc4jZaEvQUMyvnaVNXX 8awAnRjij2X9+qCDqatbz7BiAxYcukh0 =HXNt -END PGP SIGNATURE-
Re: inline sweave / knitr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31/01/12 09:52, Liviu Andronic wrote:
> On Sun, Jan 29, 2012 at 10:15 PM, Yihui Xie
> wrote:
>> On Sun, Jan 29, 2012 at 2:47 PM, Jack Tanner
>> wrote:
>>>
>>> OK, this is reproducible for me in 2.0.2 with Sweave (not
>>> knitr). Insert->Custom Insets->S/R Expression creates an inset
>>> that does not take input until you double-click it. (Maybe the
>>> inset is collapsed by default, like Liviu suggested, but I
>>> don't know how to check that.) Let me know if you want me to
>>> file a bug.
>>
>> I vaguely remember there is a parameter that can control this
>> (make the inset uncollapsed by default) in the module definition,
>> but I cannot find it in the customization manual now.
>>
> I'm not sure that this can be controlled. I remember looking at it
> once, and not finding any relevant option.
>
>
>> I do not know if this is worth a bug report, but usually I just
>> use Ctrl+L to input \Sexpr{} manually which has been working well
>> with me (I find it slow to go to the menu and click).
>>
> You can always assign a custom inset to a key binding. See [1] and
> try \bind "C-i s" "flex-insert \"S/R expression\""
That's what I did while having the same problems with inserting an
inset (see thread "Inserting inset via menu keyboard shortcuts
problem" on the LyX mailing list).
Just check the thread - the problem went away after renaming .lyx
folder, restarting LyX, quitting, deleting new .lyx folder and naming
the old one back to .lyx.
So just try with a new .lyx folder if the problem persists.
Cheers,
Rainer
>
> in your 'bind' file. Moreover, things will be improved when [2]
> gets addressed. Liviu
>
> [1] http://www.lyx.org/trac/ticket/6786 [2]
> http://www.lyx.org/trac/ticket/7877
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8nru0ACgkQoYgNqgF2egoDCQCeKi6oEVZCMBom0sDcn/ShFfbO
5vAAn1YHfCW9xewpkZAKk1QoiQMlEJKF
=ZKnO
-END PGP SIGNATURE-
Re: Sluggish performance in some tabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/12 14:40, Vasek wrote: > Gustav Eje Henter ee.kth.se> writes: > >> >> Hello LyX people, >> >> Thank you for a wonderful piece of software! Unfortunately, I've >> been seeing performance issues for a while which have been >> slowing my work. >> >> The issue is that some tabs are very sluggish. Scrolling takes >> approximately > one >> second per tick on the mouse wheel, and similarly for Page >> Up/Page Down. > Typing >> sometimes lags many characters behind, math mode being >> particularly bad at approximately one character per second. This >> appears not to be related to document length. >> >> The weird part is that the issue occurs on a per-tab basis. After >> having been open for a day, some tabs revert to normal speed >> again. Fast tabs can also become slow, particularly when new tabs >> are opened. Today, however, I noticed that it is possible to have >> a slow and a regular-speed tab open simultaneously in the same >> instance of LyX (performance depends on which tab that is >> active), which is what made me contact you. >> >> Checking top shows that memory is not an issue, but that a large >> fraction of user CPU is consumed by Xorg during slowdowns. >> http://wiki.lyx.org/Tips/PerformanceIssues states that "When top >> shows that > 90% >> of CPU time is taken by X and not LyX there is something to be >> done with your > QT >> & X settings not LyX itself." Is this still applicable if only >> certain tabs > are >> affected? >> >> For the record, I am running LyX Version 2.0.0 (Friday, April 29, >> 2011), the latest binary distributed with my Ubuntu 11.04 system. >> My computer is a Dell Latitude laptop with an Intel Core2 Duo >> T7500 (2.2 GHz) and several Gigs of > RAM. >> I'm running Gnome 2.32.1 (build date 2011-04-14) -- not the Unity >> interface -- with desktop effects disabled, and I am using the >> official NVIDIA drivers version 270.41.06. My test documents are >> four-page scientific paper drafts > with >> nothing too heavy inside, but with a little bit of everything >> (references, > math, >> a figure, and a table). >> >> Do you think this is a LyX issue or not? I looked at a few perf >> bugs on Trac > but >> didn't see anything compelling. >> >> Best regards, Gustav Henter >> >> == >> >> Gustav Eje Henter, Ph.D. student E-mail: gustav.henter ee.kth.se >> Sound and Image Processing Lab, EES,Web: >> http://www.ee.kth.se/sip/ KTH - Royal Institute of Technology, >> Stockholm, SWEDEN >> == >> >> > >> > > Hi, I had the same problem on 11.04. Upgrade to the latest version > solved it for me. I did the following: > > 1. run: sudo apt-get build-dep lyx > > 2. Download source packages for the latest LyX from precise: > http://packages.ubuntu.com/precise/lyx [lyx_2.0.2-1ubuntu1.dsc] > [lyx_2.0.2.orig.tar.gz] [lyx_2.0.2-1ubuntu1.debian.tar.gz] > > in a temporary folder, and run dpkg-source -x > lyx_2.0.2-1ubuntu1.dsc > > 3. build package: cd lyx-2.0.2/ dpkg-buildpackage -rfakeroot -uc > -b > > 4. install packages: cd .. sudo dpkg -i *.deb > > I worked flawlessly and performance is far better. Definitely recommended, but I experienced a considerable slow down in scrolling when floats with graphics / tables are open - may be the case for you as well? Rainer > > Vasek > > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk8EWekACgkQoYgNqgF2ego/oQCXTRxCmKJKyEa/Swo699B7+hHW 1ACeMn2nSu9SEiAqEZRTDC4Mkfkb97Q= =4/Vy -END PGP SIGNATURE-
Re: Packaging for ubuntu / debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/11 20:15, Georg Baum wrote: > Pavel Sanda wrote: > >> Rainer M Krug wrote: >>> easier to create binaries consistent with the official builds >>> by ubuntu? >> >> sure we can add them. but the info must be provided by the >> ubuntu/debian maintainer, which is not on this list (afaik). > > It is even worse: Currently, there is no debian maintainer for LyX, > since the previous one (Sven Hoexter) has no time anymore. Yes - that is a real pity. > If there is a new volunteer, and the LyX project wants to give him > svn access, it would indeed be a good idea to develop the packaging > in the LyX source control. That would definitely be the best approach. > IMHO it is impractical if he would need a proxy developer to get > stuff in. For now, you can always get the latest packaging stuff > from http://wiki.debian.org/PkgLyx. Until there is a new debian maintainer of LyX, that approach should be followed. Am I right in assuming that only the debian directory needs to be included in the source? In addition: notmuch had an additional make rule for creating a package (debian-snapshot), which made building the package *very* easy. I just paste here the section): .PHONY: debian-snapshot debian-snapshot: TMPFILE := $(shell mktemp) debian-snapshot: make VERSION=$(VERSION) clean cp debian/changelog $(TMPFILE) EDITOR=/bin/true dch -b -v $(VERSION)+1 -D UNRELEASED 'test build, not for upload' echo '3.0 (native)' > debian/source/format debuild -us -uc mv -f $(TMPFILE) debian/changelog echo '3.0 (quilt)' > debian/source/format So I simply had to extract the source from the tar file and execute "make debian-snapshot" and it created all the deb files. Cheers, Rainer > > > Georg > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7hzvsACgkQoYgNqgF2egrb4gCfYUUkJOZuW1wnf8RZIrtTk17B M2YAn2ulUlsL+kxWt2fTLBatBIrn5NHB =lQIt -END PGP SIGNATURE-
Re: Packaging for ubuntu / debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/11 16:30, Kornel Benko wrote: > Am Donnerstag, 8. Dezember 2011 um 16:09:35, schrieb Pavel Sanda > >> Rainer M Krug wrote: >>> easier to create binaries consistent with the official builds >>> by ubuntu? >> >> sure we can add them. but the info must be provided by the >> ubuntu/debian maintainer, which is not on this list (afaik). >> pavel > > You can use the cmake build. This is *my* workflow on ubuntu: > > # cd /usr/src/lyx/lyx-devel # svn up # cd /usr/BUILD/BuildLyx # > cmake /usr/src/lyx/lyx-devel > -DCMAKE_INSTALL_PREFIX=/usr/local/lyx2.1 \ -DLYX_CPACK=ON > -DLYX_PROGRAM_SUFFIX=OFF -DCPACK_BINARY_RPM:BOOL=OFF \ > -DCPACK_BINARY_DEB:BOOL=ON -DCPACK_BINARY_NSIS:BOOL=OFF \ > -DCPACK_BINARY_STGZ:BOOL=OFF -DCPACK_BINARY_TGZ:BOOL=OFF \ > -DCPACK_BINARY_TBZ2:BOOL=OFF -DCPACK_BINARY_TZ:BOOL=OFF \ > -DCPACK_SOURCE_TBZ2:BOOL=OFF -DCPACK_SOURCE_TGZ:BOOL=ON \ > -DCPACK_SOURCE_TZ:BOOL=OFF -DCPACK_SOURCE_ZIP:BOOL=OFF \ > -DLYX_EXTERNAL_BOOST=OFF -DLYX_HUNSPELL=on \ -DLYX_ENCHANT=ON > -DLYX_NLS=ON -DLYX_EXTERNAL_LIBINTL=OFF # make -j5 package # sudo > dpkg -i /usr/BUILD/BuildLyx/lyx-2.1.40439-Linux.deb > > 1.) You have to adapt the source dir (here /usr/src/lyx/lyx-devel) > and the build dir (here /usr/BUILD/BuildLyx). 2.) You don't need > svn up, if you got the sources from e.g. a tar file 3.) "make > package" creates a package with svn-version in the name, so the > created package likely will be different from > "lyx-2.1.40439-Linux.deb" Thanks - always nice to see a different approach. I used checkinstall for creating the deb: ./configure . ./make ./checkinstall And it is working, but, as you point out below, it is not following the ubuntu / debian packaging principles. And that was my idea: to provide these packaging rules, and to make it easy to create the official debs based on the newest versions of LyX. Cheers, Rainer > > > This is *not* the same as provided by ubuntu/debian maintainer, but > I use it for ages now without problems. > > Kornel > > > > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7hy4MACgkQoYgNqgF2egocrACfSG2oFBCAjvZak3OTDj5ig0+o WqEAniyf3dAF7/e/Ol3supsFIR1aZBw2 =3DNe -END PGP SIGNATURE-
Re: Packaging for ubuntu / debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/11 15:55, Richard Heck wrote: > On 12/08/2011 05:01 AM, Rainer M Krug wrote: >> Hi >> >> I just installed a program called notmuch, and I was told that >> the debian packaging info is included with the source, so that I >> could build the official deb packages easily with a single make >> command. >> >> I do not know how much is involved, but would this be possible >> for LyX as well? One could probably include the rules for other >> packaging systems as well, and make the building more consistent, >> and the creation of binaries on Launchpad finally working, or at >> least much easier to create binaries consistent with the official >> builds by ubuntu? >> > There is a spec file for RPM builds in the LyX source, though I > don't know how up to date it is. So I don't see why we could have > Debian stuff in the tree as well. I assume you wanted to say "could not have Debian stuff"? Rainer > > Richard > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7g0cEACgkQoYgNqgF2egrHswCeNZnfcqJY2RUw5KuAYJ/MLvQA DSUAn3MRDiDeILma+buYtyBDGeN2pQtz =FpQf -END PGP SIGNATURE-
Packaging for ubuntu / debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I just installed a program called notmuch, and I was told that the debian packaging info is included with the source, so that I could build the official deb packages easily with a single make command. I do not know how much is involved, but would this be possible for LyX as well? One could probably include the rules for other packaging systems as well, and make the building more consistent, and the creation of binaries on Launchpad finally working, or at least much easier to create binaries consistent with the official builds by ubuntu? Cheers, Rainer - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7givgACgkQoYgNqgF2egoINACeOUA7mgPhjjlbyYnWvethAgDm lmYAnjD8ZUUGZzFy0Z5rYf8QIOpl079y =sK0T -END PGP SIGNATURE-
Re: Collaborative real-time editing (#7859)
On Wed, Nov 30, 2011 at 1:02 PM, Benjamin Piwowarski wrote: > Hi to all, > > I am slowly getting acquainted to LyX development by fixing small bugs for > the moment, but I would like to investigate how much collaborative > real-time editing is a possibility given the current code - Is LyX ready > for this, or would it need to change the architecture? Many thanks for your > opinions about that. > There was a long discussion about that on the mailing list some time ago, and I am not sure if there was a consensus if this is useful - I think the subject was " **Strategies for Writing Co-operation with Non-LyX Users?" but I am not sure. Cheers, Rainer * > *Benjamin -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: Ideas for Development
On Thu, Nov 24, 2011 at 8:38 AM, Xu Wang wrote: > Could say a little bit what yWriter is? I just looked at http://www.spacejock.com/yWriter5.html and yWriter sounds a lottle bit like lyx-outline which Rob Oakes is working on ( http://www.oak-tree.us/lyx-outline/)? Am I rightn, If this is true, something like it would be brilliant, and I would suggest you get in contact with Rob and bounce some ideas. Cheers, Rainer > for Number 2, is tools>preferences>editing>scroll below end of document > what you're looking for? I think this is only in 2.0 and later. > > Xu > > > On Wed, Nov 23, 2011 at 7:10 PM, Graham Telfer > wrote: > >> Hi there, >> >> I am using LyX now and would like to suggest 2 ideas for development. The >> first >> one is a big idea which would probably need to become a whole project in >> itself. >> >> 1. Extend LyX to become a writer's project management tool similar to >> yWriter. >> yWriter is targeted at novelists but something like this would be great >> for >> scientific and technical writers too. LyX would be a great starting point. >> >> 2. When in full screen mode have the option to keep the cursor centred >> and text >> above and below a few lines fade out as in the ipad editor iA Writer. >> >> > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: Tolerating future file formats ?
On Mon, Sep 19, 2011 at 12:03 PM, Tommaso Cucinotta wrote: > Il 19/09/2011 08:47, Guenter Milde ha scritto: > >> On 2011-09-19, Vincent van Ravesteijn wrote: >> >>> You should not let the development LyX interfere with your system-wide >>> LyX. >>> >> For me, the following works: >> >> >> ./configure --with-version-suffix=-svn --enable-build-type=release >> >> >> The "--with-version-suffix" option tells LyX to use a different name for >> the >> executables as well as the config directories. >> > > Sure, this is the right cure for developers and for my specific problem. > > The rationale behind my message was simply that I'm shocked by the fact > that we have a program that at a certain point refuses to start or load a > document voluntarily, leaving the user with the only option to ask for help > to others (us). Actually, the specific configuration line, or document > line/paragraph, that is causing the trouble might be simply skipped with a > WARNING to the user, and the program would self-fix the situation (with the > user awareness that he/she should cross-check whether anything got lost). > Actually, having some kind of (fault-)tolerance like this would also help in > cases of corrupted files due to a number of reasons (one of them that comes > to my mind might also be conflicts while having .lyx files on a shared SVN > repo). > > For example, popping up a dialog with something like: > "WARNING: LyX detected a more recent file-format than the one that it is > able to handle. You can try to keep loading the document at YOUR OWN RISK, > with possible data losses, inconsistencies and corruption of the file (or > crash of the program). If you want to be on a safe side, then choose CANCEL. > If you really know what you're doing and decide to proceed, at least be sure > to save the file with a different name on the filesystem." > I think that under these circumstances, saving under a different name should be *compulsory*. > > Letting the user choose between "Keep Going" and "CANCEL" ? > > or, if we parse something bad inside the document (despite the correct > document format): > > "WARNING: LyX detected an inconsistent contents of this document file. You > can try to keep loading the document " > > .. and a similar question for the non-understandable configuration file > > Just take this as a desirable "feature" (or bloat :-) ) request. > > Bye, > >T. > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
