change font base size mid document
I have an 11 pt article. I want to switch to a base size of 10pt for the Appendix. Is there a way to do this that will not cause trouble with e.g. text in superscripts or figure legends with different size fonts? I found these suggestions http://tex.stackexchange.com/questions/4139/how-to-change-font-size-mid-document but \input{size#1.clo}% completely reset margins etc while \fontsize{10}{12}\selectfont had no effect. Many thanks, Greg. -- Gregory Jefferis, PhD Division of Neurobiology MRC Laboratory of Molecular Biology Francis Crick Avenue Cambridge Biomedical Campus Cambridge, CB2 OQH, UK http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2 http://flybrain.stanford.edu
Re: Spellchecking not working on Mac OS X
On 19 Apr 2013, at 08:25, Grant Jacobs wrote: > A work-around seems to be to select the document language to be what you > want (e.g. English (UK)) and select that to become LyX's default > document language. This isn't particularly intuitive (one might expect it to be accessible from the main Preferences window, Language tab, perhaps it isn't because it is somehow tied to different document classes) but it does work just fine for me with 2.0.5-1 with English (UK). Is there an outstanding issue that this doesn't solve? Best wishes, Greg.
Re: OTish: Illustrator alternative to collect linked PDFs into single figure
On 14 Feb 2013, at 09:58, Mukhtar Ullah wrote: > Scribus is what you need. > http://scribus.net/canvas/Scribus Thanks a lot for the suggestion, I'll look into that more carefully. But do you know if it can 1) include linked pdfs (ie so that content will update when the external file updates) 2) do so retaining vector elements in the linked PDF (rather than immediately rasterising). Many thanks, Greg.
OTish: Illustrator alternative to collect linked PDFs into single figure
Hello, We currently used Adobe Illustrator to construct quite complex figures for Biological Science manuscripts. We save in PDF compatible format and then directly place these in my lyx document. Apart from being expensive, the main problem is that Illustrator always saves the absolute path to any linked file causing trouble when colleagues edit these files on different machines. Our figures mostly consist of linked PDFs, some type e.g. for labels and a small amount of drawing for annotation. I would like to switch to a FOSS alternative that allows PDFs to be linked (not embedded). The detailed layout of the elements is important. The closest I have found so far is Inkscape, but this always embeds PDF on import. Likewise it does not yet seem to be able to support linked SVG files. Would anyone have any suggestions? Many thanks, Greg. http://inkscape.org/ -- Gregory Jefferis Lab: jefferis...@gmail.com Division of Neurobiology MRC Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 0QH, UK. http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2 http://flybrain.stanford.edu
Re: moderncv
On 14 Jan 2013, at 18:35, Hansen, Glenn J. wrote: > Thank you in advance for the help. I am new to lyx/tex. > > I have been trying to get my cv moved to lyx/tex format and have ran into a > problem that I am not able to solve. I have nearly everything done but > getting a multiple sectioned bibliography to work(e.g., section for journal > articles and conference papers). I get the following error: > > "! Package bibtopic Error: Found unknown `thebibliography' environment." The error message includes the additional information: You should either use a package providing a known bibliography environment (such as natbib), or use the `defaultbib' package option as a workaround; please see the section about `Warnings and error messages' in `bibtopic.dvi' for details. If you go to: Document ... Settings ... Document Class ... and then edit the Custom field to add defaultbib then as far as I can see things should work. Best, Greg. -- Gregory Jefferis, PhD Division of Neurobiology MRC Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 0QH, UK. http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2 http://flybrain.stanford.edu
Re: LyX document diff/merge tools for cooperative editing?
On 3 Jan 2013, at 15:35, Gour wrote: > I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks > interesting. maybe cc yourself on ticket to indicate your interest, but existing document comparison produces poor results as noted here: http://www.lyx.org/trac/ticket/6889 so you might want to comment on that one / cc as well. > > After deciding to use LyX as the tool for writing manual for software > application which will be kept under DVCS (not git, but most probably > Fossil), I just wonder what are your experiences with different diff > tools? > > In one blog post, I saw that Emacs' ediff was much better thant e.g > KDiff, Vim's diff... > (http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml) > but considering that so far I only keep my own docs under DVCS, I'm > interested what one can expect when diff-ing LyX documents in order to > try to provide merge of changes? line based diff works poorly out of the box with justified latex paragraphs as noted in that blog. This problem is actually somewhat less severe with lyx since it automatically breaks lines after every period in the text and where any change of formatting occurs. In my experience I have found built-in diff merge with git works perfectly well. If you want more fine grained display of differences (the patches will be the same) see e.g.: http://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/ I imagine fossil may have a similar option to --color-words. Best, Greg.
Re: LyX document diff/merge tools for cooperative editing?
On 12 Dec 2012, at 13:49, Pavel Sanda wrote: >> I think the idea of merging is pretty obvious ? > > If you mean "git merge" then I'm happy to tell you that some people I need to > work with even don't > know what is command line in which you can write the command or decrypt > whatever comes from git > in case of conflict :) > > One solution would be to detect merge conflicts and call our diff algorithm > for the different versions. that is exactly what I had in mind > This would be beautiful but an order of magnitude harder to implement (surely > not me:) I don't think it is that hard. The SVN VCS support already in git offers the option to fetch remote changes and then the option to do something about conflicts if they exist (at the moment, just keep local or remote). for git this would mean 1) "pull" (presumably if the current branch is a tracking branch) 2) if the merge is successful then just reload the buffer 3) if it fails (and there are clear signals from git when this is the case) diff the local and remote documents _inside_ lyx to give some tracked changes that the user then needs to accept/reject. That really doesn't strike me as that hard to implement (iff the diff did something useful). >> if you wanted to have bare bones support for git in lyx you would need >> * commit (saving your changes) >> * push (share your work) >> * pull (fetch changes and merge with your work) > > I know what I need, but the question was about your workflow. > In particular, does it make sense in your case to automatically push after > commit? For us, push on commit is fine. We basically try to pull immediately before starting to make changes and push as soon as possible afterwards. This way we very rarely have trouble. However, I think some would prefer to wait to push until they had accumulated a few related changes, so it would be nicer if a design allowed this. Looking a little bit at the existing VCS class and the toolbar, I guess there isn't immediately a way to support commit without push, because svn does not have that separation. >> After testing out the existing svn implementation I think this is actually >> simpler to automatically merge with git than to lock files with svn. > > Maybe more powerful, but simpler? I have hard time to understand how > resolving merge conflicts is _simpler_ than automatical locking part of the > document you work on. when merging works (and this is 99% of the time for us) it is simpler. When there is conflict it is indeed much harder – and that is the problem that a functional diff in lyx could solve. > But Ok, we don't agree here, let is sleep. OK! >> what would be more important for my workflow is the ability to do merges by >> a functional diff in lyx. > > This is the key point and I recommend that you add some comment or > CC-yourself in bug #6889 > to indicate that this bug hunts more people and add it more importance... Good point. I have now done so. Nico, I guess it might be good if you did the same. Pavel has already proposed a work around that looks relatively simple to implement and ought to reduce the number of changes significantly, so there is some chance that this will get picked up and improved. Ticket is here: http://www.lyx.org/trac/ticket/6889 Best, Greg.
Re: LyX document diff/merge tools for cooperative editing?
(wrote this up and noticed that much of it duplicates what Nico said – merging is easy and branching is not so bad either) On 11 Dec 2012, at 18:25, Pavel Sanda wrote: > Nico Williams wrote: >> It is precisely because locking doesn't scale that we have branching >> and merging. Locking simply does not scale. This is true even of >> documents (as opposed to source code). I definitely agree with Nico. Even for a small group, concurrent editing and automatic merging is a major productivity boost. For example we are in the final stages of finishing a manuscript. More often than I care to admit it's late in the evening and we're saying: I'll do the intro, A do the methods, B fix the problems in supplemental, C check the figure/table references. > Conditions I had in mind were: > a) > - small team working on e.g. scientific paper > - avoid endless email exchanges of manuscript (locking exists by definition) there really isn't a way to lock in git so this is out > - only subset of people are "IT-aware" while the others are capable at > most of "push the red button" to commit the change and unlock the > given chapter. > b) > - private document where VCS is used just to store history ("just for sure") > > In such world even knowing what "merging" or "branching" means qualifies I think the idea of merging is pretty obvious – after all you can merge changes in Word but it's harder and much more involved/error prone than doing with git. if you wanted to have bare bones support for git in lyx you would need * commit (saving your changes) * push (share your work) * pull (fetch changes and merge with your work) After testing out the existing svn implementation I think this is actually simpler to automatically merge with git than to lock files with svn. I admit that branching seems more complex and one could pass on branch handling for a basic git in lyx implementation. But branching (and then merging those branches) are super easy with git and I have been surprised at the takeup by people in my lab who are really not that techie. I used subversion for several years and almost never branched (and dealing with merges was nasty). Branch (and merge) in git was a revelation. Incidentally LyX itself already has support for "branches" aka different versions of the same document, which is a related idea. > you as someone who really does not need LyX to manipulate version tracking > and who will stay happily with specialized software or command line :) However, I think it is true that there are lots of good external tools for git so "git in LyX" would be nice (and it would stop me making the occasional mistake of not saving and closing my lyx doc before commiting/pushing/pulling) but what would be more important for my workflow is the ability to do merges by a functional diff in lyx. Best, Greg.
Re: LyX document diff/merge tools for cooperative editing?
On 7 Dec 2012, at 17:46, Nico Williams wrote: > On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug wrote: >> On 07/12/12 12:45, Gregory Jefferis wrote: >>> Has anyone tried using latexdiff for change comparison in not merging? >>> Presumably a small script to export both versions to latex, invoke >>> latexdiff and then generate the marked-up PDF (which is what you get with >>> latexdiff) would work. For latexdiff there are already scripts to handle >>> git revisions which should allow one to diff a pair of arbitrary revisions >>> in a git repository. >> >> This should work, but it would be really nice if these changes were on LyX >> level and that one could >> save a file LyX file containing the differences as tracked changes. > > Right, the goal is to merge LyX documents. Unless converstion to/from > LaTeX is loss-less this is not a solution. Just to clarify (since it was apparently not clear) my suggestion re latexdiff was specifically about change *comparison* not merging (though I had admittedly wondered about the possibility of a round trip via latex). But for me seeing changes in context is half the battle! Returning to the original question of merging + VCS, we currently use git + lyx for collaborative editing of papers in the lab (normally <=3 people) using git's built in merge. For us this a tremendous improvement over the emailed word file strategy. We have not managed to break a LyX file with an inappropriate automated merge. Merge conflicts are obviously possible if 2 users edit the same piece of text but in our use very rare – we encourage frequent push/pull, avoid e.g. fixing spelling errors all across the document without checking that changes have been committed and pushed. But on the rare occasions when conflicts do happen they unfortunately a showstopper for most users. It would indeed be very nice to have the option to merge in LyX when this happens, when one would typically use git mergetool. However, I do note that when a merge conflict happens, the file with conflicts left marked by git's regular merge or what you typically get by using git mergetool to start a generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That means you only have to worry about the *conflicts* not the compatible changes in each branch. So in these circumstances firing up a text editor to fix the conflict might be much quicker (albeit more dangerous) than using LyX to accept/reject all changes displayed in a 2 way diff. In some sense a strategy that turned conflict markers into LyX tracked changes (or a 3 way diff) is really what one is after. When I am working with less tech savvy people outside the lab, I usually tell them to use track changes (and commit their work manually to git). You can even consider asking people to use track changes when using a VCS if someone is going to review all changes for integration. Regrettably there is still the possibility of merge conflict even after the discussion/fix noted here: http://www.lyx.org/trac/ticket/6058 if two or more people both start tracking changes before merging to master. Hope some of this experience might be of use. Best, Greg.
Re: LyX document diff/merge tools for cooperative editing?
On 6 Dec 2012, at 08:05, Rainer M Krug wrote: > I agree with this comment - I wanted to use the comparison tool for comparing > two revisions, and > the result was simply unusable. Has anyone tried using latexdiff for change comparison in not merging? Presumably a small script to export both versions to latex, invoke latexdiff and then generate the marked-up PDF (which is what you get with latexdiff) would work. For latexdiff there are already scripts to handle git revisions which should allow one to diff a pair of arbitrary revisions in a git repository. http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/ > But a compare tool from commandline would be exceedingly useful for VCS. +1. Greg.
Re: Download problem... LyX dmg "not recognized"
On 2010-10-07 10:12, "Bettina" wrote: > Hey - I want to dl LyX for Mac. I tried it on the Download page > (http://www.lyx.org/Download#toc4), but ftp login and password are required. > When I downloaded the LyX-1.6.7-Mac-Universal.dmg file from CNET, the disk > image > could not be mounted... Anyone who could help me out? Seems like ftp.lyx.org is accessible but anonymous ftp is off at the moment. Greg.
Re: more on collaboration
On 2010-09-25 06:51, "Jose Quesada" wrote: > I tried Gobby. it's as simple as notepad, so for serious programming/writing > it'd feel a bit limited. But the deal breaker is no undo. Yes, you hear that > right. I think Gobby is actually feature-wise worse than in-browser > alternatives. For anyone who wants to do real time latex editing, then I have come across two possibilities. 1) SubEthaEdit as already mentioned, really nice collaborative editing for many users, simple to setup, fairly simple latex mode, macosx only, commercial 2) Eclipse + Texlipse + Eclipse Communication Framework (ECF) and in particular the DocShare plugin. basic collaborative editing, appears to be limited to 2 people, a bit of a pain to setup, good latex support, cross-platform, open source ECF provides an example of how building a collaborative editor can be layered on top of existing work. See: http://wiki.eclipse.org/RT_Shared_Editing I guess if LyX had a round-trip consistent latex export/import these might even provide an option for online collaborative editing of text from a LyX document. Best, Greg.
Re: more on collaboration
On 2010-09-26 17:07, "Pavel Sanda" wrote: > Gregory Jefferis wrote: >> We use version control (git) + to write papers in the lab. It works fine >> but handling merge conflicts is still difficult; the chaps in the lab are > > in one project we 'solved' this via locking. the document could be split > into childern (=chapters/sections) so multiple people can still work > simultaneously. Thanks for the suggestion. I can see that could work but it does seem a bit of a blunt instrument. We would need to change VCS (git has no locking AFAIK). But I'll keep it in mind. >> LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is only >> partly solved in 2.0. See: http://www.lyx.org/trac/ticket/6058 And in particular my post (+patch) which tries to explain why what has been implemented for Lyx 2.0 is still fragile: http://www.mail-archive.com/lyx-de...@lists.lyx.org/msg153396.html In brief, if you have a document under version control and two users turn on track changes, then their changes will get confused in both 1.6.X and 2.0. In 2.0 this can be avoided if the first user pushes (in git terminology) and the second under pulls before the second user turns on track changes. However in practise this will often be violated (e.g. when you ask all co-authors to edit/comment on a given draft).
Re: more on collaboration
Hi all, I would distinguish two kinds of collaborative editing. * interactive collaborative editing - 2 or more people working simultaneously on a document * non-interactive collaborative editing - only one person actually modifying the document at any one time BUT others always having live access to the latest version if required. I think typically you would spend 5% of writing time in the first mode but that implementing it solves nasty problems with collaborating in the second mode. More specifically: On 2010-09-24 17:41, "Richard Heck" wrote: > On 09/24/2010 11:43 AM, Les Denham wrote: >> On Friday 24 September 2010 10:29:10 Rob Oakes wrote: > I have to confess that I too am somewhat puzzled by this, but I can see > a use case that would be good for me. Say I've written a paper with a > collaborator. We are now at a pretty late stage in the process. It might > be useful to be able to read through the document together and make > changes we can both see "in real time". I'm not saying this really would > be all that great, but I can see using it. This is the kind of situation where actively using real time editing is really useful and for me it crops up whenever I am writing something with a colleague for another institution. It is incredibly motivating and leads to better writing if you can skype and write in an _interactive_ and collaborative fashion. There are potential low tech ways to do this using screen sharing, but they do lose the significant benefit of attaching edits. Furthermore since you don't usually want to have a permanent share of your desktop you can't leave them on the whole time and that for me is the problem - in my view the real benefit of a rich collaborative editing implementation is that allows much easier and more consistent - non-interactive collaborative editing. Non-interactive collaborative editing means that there can always be one live version of a document to which anyone can apply changes that are versioned, identified and much more likely. Essentially it solves the conflicting merge problem by automatically merging all the time so that you are always looking at the latest version (and can be alerted to recent changes). You can try and do this with traditional version control arrangements but you will always run into a conflict if the system isn't designed for the possibility of interactive collaborative editing. Does this seem reasonable to others? Or have other people found ways to solve the non-interactive collaborative writing situation when people end up modifying the same document. In my experience this happens often enough that it's a problem and existing software that I am aware of makes it too hard to solve for most researchers. Greg.
Re: more on collaboration
Hi Kevin, Jose et al, We use version control (git) + to write papers in the lab. It works fine but handling merge conflicts is still difficult; the chaps in the lab are all very computer literate but I regularly have to help out with a broken merge. It's certainly too complicated for me to insist on with external collaborators. For them I initially suggested LyX + track changes. However LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is only partly solved in 2.0. The beauty of real time editing is that it handles merge conflicts in a way that is easy to understand and really pretty transparent. Of course for it to be transparent, there has to be a clear way to see who (and ideally when) last edited any piece of text. For my group and colleagues beyond the lab, collaborative editing (a la SubEthaEdit) would be the killer feature that would really expand the audience for LyX. I hope that at some point this will resonate with one of the developers with the skills to implement this kind of feature. Best, Greg. -- Gregory Jefferis, PhD Division of Neurobiology MRC Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 0QH, UK. http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2 http://flybrain.stanford.edu
Bibunits example only generates one of 2 bibliographies
I am trying to make an article with 2 bibliographies. To get me going I am starting with the example on the wiki: http://wiki.lyx.org/Examples/Bibunits However when I make a PDF I do not get one of the bibliographies. Apparently it is not being processed by bibtex. When I copy the bib files (refs.bib) into LyX's temp dir, and run bibtex manually and regenerate the PDF, everything works. There is a hint on the wiki which is supposed to solve this problem: Hint: The problem that LyX does not find the extra aux files for bibunits can be solved without running bibtex manually and without a shell script. Just add the following to the preamble, and LyX will automatically run bibtex on the extra files: \makeatletter \renewcomman...@bibunitname}{\jobname.\the\@bibunitauxcnt} \makeatother But it is obviously not working for me. Would anyone have any fixes/workarounds/insight? Thank you very much your help, Greg. Sys details: OS X 10.5.8 LyX 1.6.4.2 MacTex/TeXLive 2009 -- Gregory Jefferis, PhD Division of Neurobiology MRC Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 0QH, UK. http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2 http://flybrain.stanford.edu
Re: Cross References with Export to HTML (Word)
Replying to my own question: On 2009-06-03 22:40, "Gregory Jefferis" wrote: > I want to do a respectable export of to something that Word can open for final > submission to a journal. My document has bibtex references and multiple > figures (present as floats from which I have removed the actual graphics file > because I only need the text in my export). After a lot of experimenting the > best looking output so far comes from Export to HTML (MS Word). However > although the main body of the text and the citations and reference list come > out ok the figures are causing trouble. Specifically the cross references to > figures in the text are all rendered as ??. > It seems that there is an interaction with the babel package. When I turn off babel, export of figure cross references work fine. Perhaps my babel (from MacTex2008) is broken - I have not tried to update. (Preferences ... Language ... Language Settings: Use babel checkbox) > Suggestions for alternative export paradigms are also welcome but for me: > > 1) Export to ODT produces a corrupt output file. This is also true for Open Document (ODT) export which previously zipped up all of the latex intermediate files in the temporary directory producing a file that was unintelligible to OpenOffice. Best wishes, Greg. > LyX 1.6.2 on Mac 10.5.6
Cross References with Export to HTML (Word)
Hello All, I want to do a respectable export of to something that Word can open for final submission to a journal. My document has bibtex references and multiple figures (present as floats from which I have removed the actual graphics file because I only need the text in my export). After a lot of experimenting the best looking output so far comes from Export to HTML (MS Word). However although the main body of the text and the citations and reference list come out ok the figures are causing trouble. Specifically the cross references to figures in the text are all rendered as ??. I'm sure this is an FAQ, but I've searched both wiki and archives and can't seem to find anything. I would really appreciate any help at this point. Suggestions for alternative export paradigms are also welcome but for me: 1) Export to ODT produces a corrupt output file. 2) Export to RTF does not render citations but just produces the labels (ie \citep{root2008} in the source goes to root2008 in the output) Thank you so much for your help, Greg Jefferis. LyX 1.6.2 on Mac 10.5.6 -- Gregory Jefferis, PhD Division of Neurobiology MRC Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 0QH, UK. http://www2.mrc-lmb.cam.ac.uk/NB/jefferis_g http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2 http://flybrain.stanford.edu