export to odt and HTML (Word)
On my LyX 2.0.4, Windows, export to odt and HTML (Word) is very broken. For example, at times I get this in messages: 23:14:21.748: C:\Users\lunacy\AppData\Local\Temp\lyx_tmpdir.Hp8096\lyx_tmpbuf3>t4ht my-doc.tex "-cooxtpipes -coo" -ewin32/tex4ht.env 23:14:21.751: --- error --- Illegal storage address but then I also get: 23:14:21.772: Successful export to format: odt 23:18:42.401: Automatic save done. Naturally, the export fails, i.e., neither the temp dir nor the actual doc dir contain an exported file.
RE: [PATCH] LFUN_BUFFER_FORALL
From: Jean-Marc Lasgouttes [lasgout...@lyx.org] Sent: Wednesday, July 18, 2012 4:14 AM JMarc, Thank you for your guidance. Attached is an updated patch and below I respond to your comments. Scott >Try to #include "GuiWorkArea.h" at the start of GuiApplication.cpp. That works. >> + case LFUN_BUFFER_FORALL: { >> + GuiView * cv = currentView(); >What if currentView() is null? I propose to do an early return in this >case. Or maybe this can happen when all buffers are hidden and requires >finer codeing. I do not know whether this is only a theoretical >possibility, this may happen when using client to do scripting. On the >mac at least, LyX can be running witout having any open window. >Unless you want to be very complete, it is probably enough right now to >return early. I wouldn't mind trying to address this if you think that would be better. For now I don't allow for this situation by disabling the function in getStatus. I didn't realize that it's possible to have a hidden window without a visible window. The current patch disables the function in this situation. I don't know how to check for the existence of a hidden buffer without a visible buffer. >I do not think I have seen "cv" used as the name of a GuiView. From a >quick poll if the source, I suggest "gv" or "view". The good thing about >using a known name is that it requires less effort for the reader of the >code. Done. >> + Buffer * const buf = &cv->currentBufferView()->buffer(); >Do we have a bufferview when the LyX window is there but no buffer is open? I put in some checks. >> + FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun); >FuncRequest const funcToRun =... >(constify and no capitalization of variable names) Done. >> + dr.setMessage(bformat(_("%1$s%2$s"), msg, >> from_utf8(commandToRun))); >> + Buffer * const last = theBufferList().last(); >> + Buffer * b = theBufferList().first(); >> + Buffer * nextBuf = 0; >> + // We cannot use a for loop as the buffer list cycles. >> + while (true) { >> + if (b != last) >> + nextBuf = theBufferList().next(b); //get next >> now bc LFUN might close current >> + >> + bool const hidden = !(guiApp->currentView() && >> guiApp->currentView()->workArea(*b)); >No need to use guiApp-> there. Are you using currentView() because cv >could become invalid? If so, why do you use it below? Done. >BTW, what happens if several windows are open? It looks like you are not >going to see whether the buffers on other windows are If there are more windows open, buffer-forall iterates over the buffers in the current window, treating a buffer as hidden as designated in the current window. When a new window is opened it treats all of the open buffers as hidden. The default of buffer-forall of not iterating over hidden buffers is thus nice in the case that a user doesn't know what a hidden buffer is or doesn't know that the buffers in the other windows would be affected by buffer-forall because they are automatically available as hidden. >> + if (hidden) { >> + if (processHidden) { >> + cv->setBuffer(b); >> + lyx::dispatch(FuncToRun); >> + GuiWorkArea * const wa = >> cv->currentWorkArea(); >> + wa->view().hideWorkArea(wa); >I am not sure that the intermediate wa variable is useful here. Done.diff --git a/src/FuncCode.h b/src/FuncCode.h index 9a7b06e..872721a 100644 --- a/src/FuncCode.h +++ b/src/FuncCode.h @@ -452,6 +452,7 @@ enum FuncCode // 350 LFUN_CLIPBOARD_PASTE_SIMPLE, // tommaso, 20111028 LFUN_IPA_INSERT,// spitz, 20120305 + LFUN_BUFFER_FORALL, // scottkostyshak, 20120718 LFUN_LASTACTION // end of the table }; diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp index 39018ce..3767e31 100644 --- a/src/LyXAction.cpp +++ b/src/LyXAction.cpp @@ -3127,6 +3127,28 @@ void LyXAction::init() */ { LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer }, /*! + * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL + * \li Action: Applies a command to all visible, hidden, or both types of buffers in the current window. + * \li Syntax: buffer-forall [] + * \li Params: : default: visible + : The command that is to be applied to the buffers. + * \li Sample: Close all Notes in all visible documents
Re: [LyX master] Read list of translated languages from a file
Le 19/07/12 00:21, Jean-Marc Lasgouttes a écrit : commit ed1515ef69d0381e9b0657cf1966f9d86e0cb25f Author: Jean-Marc Lasgouttes Date: Thu Jul 19 00:02:56 2012 +0200 Read list of translated languages from a file The previous scheme of loading all possible translations and checking whether the work is a bit too much "brute force" and causes problems on Mac OS X (documents loaded with the wrong language). In the new scheme, autotools install a file lib/installed_translations that contains a list of installed languages (the .gmo files that got installed). This file is read in Languages::readInstalledTranslations and allows to set the translated() property of each language. Kornel, this requires an adaptation of cmake (see above). On my machine the contents of installed _translations is just ar ca cs da de el en es eu fi fr gl he hu ia id it ja nb nl nn pl pt ro ru sk sr sv tr uk zh_CN zh_TW Stephan, please check that this solves problems with the Mac builds. Uwe, please check that this still works with your windows installer. If this requires to backport to branch I can do that. Richard, if this solves the problems with the Mc builds, I think this should go to branch. JMarc diff --git a/configure.ac b/configure.ac index acfa663..71a4b1c 100644 --- a/configure.ac +++ b/configure.ac @@ -180,6 +180,10 @@ m4_defun([AC_GNU_SOURCE],[]) AM_GNU_GETTEXT([no-libtool]) AM_GNU_GETTEXT_VERSION([0.16.1]) AC_LANG_POP(C) +AC_CONFIG_COMMANDS([lib/installed_translation], [ + rm -f lib/installed_translations + echo $CATALOGS | sed 's/\.gmo//g' > lib/installed_translations +]) # some standard header files AC_HEADER_MAJOR @@ -371,7 +375,7 @@ AC_CONFIG_FILES([Makefile \ development/cygwin/lyxrc.dist \ development/lyx.spec \ intl/Makefile \ - lib/lyx.desktop-temp:lib/lyx.desktop.in + lib/lyx.desktop-temp:lib/lyx.desktop.in \ lib/Makefile \ lib/doc/Makefile \ lib/lyx2lyx/lyx2lyx_version.py \ diff --git a/lib/Makefile.am b/lib/Makefile.am index 8ac88f1..2111dfb 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -8,6 +8,8 @@ dist_pkgdata_DATA = CREDITS autocorrect chkconfig.ltx external_templates \ encodings layouttranslations languages symbols syntax.default \ unicodesymbols +nodist_pkgdata_DATA = installed_translations + # We use DATA now instead of PYTHON because automake 1.11.2 complains. # Note that we "chmod 755" manually this file in install-data-hook. dist_pkgdata_DATA += configure.py diff --git a/src/Language.cpp b/src/Language.cpp index 8c891fb..9f8c57e 100644 --- a/src/Language.cpp +++ b/src/Language.cpp @@ -196,10 +196,6 @@ bool Language::read(Lexer & lex) encoding_ = encodings.fromLyXName("iso8859-1"); LYXERR0("Unknown encoding " << encodingStr_); } - // cache translation status. Calling getMessages() directly in - // PrefLanguage::PrefLanguage() did only work if the gui language - // was set to auto (otherwise all languages would be marked as available). - translated_ = getMessages(code()).available(); return true; } @@ -262,8 +258,12 @@ void Languages::read(FileName const & filename) } // Read layout translations - FileName const path = libFileSearch(string(), "layouttranslations"); + FileName path = libFileSearch(string(), "layouttranslations"); readLayoutTranslations(path); + + // Read installed translations + path = libFileSearch(string(), "installed_translations"); + readInstalledTranslations(path); } @@ -372,6 +372,32 @@ void Languages::readLayoutTranslations(support::FileName const & filename) } +void Languages::readInstalledTranslations(support::FileName const & filename) +{ + Lexer lex; + lex.setFile(filename); + lex.setContext("Languages::read"); + + // 1) read all installed gmo files names + set installed_translations; + string lang_code; + while (lex.isOK()) { + lex >> lang_code; + installed_translations.insert(lang_code); + } + + // 2) mark all corresponding languages as translated. + LanguageList::iterator lit = languagelist.begin(); + LanguageList::iterator const lend = languagelist.end(); + for ( ; lit != lend ; ++lit) { + if (installed_translations.count(lit->second.code()) + || installed_translations.count(token(lit->second.code(), '_', 0))) + lit->second.translated(true); + } + +} + + Language const * Languages::getLanguage(string const & language) const { if (language == "reset") diff --git a/src/Language.h b/src/Language.h index 71b6777..fb1158b 100644 --- a/src/Language.h +++ b/src/Language.h @@ -50,6 +50,8 @@ public: bool rightToLeft() const { return rightToLeft_; } /// Is an (at least partial) translation of this lan
Re: Undo.cpp reports an error on trunk
Le 18/07/12 17:43, Richard Heck a écrit : Looks like you never backported this particular fix. If you decide to do it, I'll backport my patch too. Which thing didn't I backport? This one, I think. JMarc commit 9283cbdbcb3b33da28d2ecca6cd5665f39c7b388 Author: Richard Heck Date: Fri Jan 13 03:31:01 2012 + Fix crash reported on list when renaming a child buffer and then trying to compile. There are really two problems here. One is that the renamed buffer needs to be reloaded. All kinds of files, etc, may not exist any more, if we've been saved to a new directory; our children e.g. may not be in the right place. And, in this case, we may no longer be a child of our old parent. Reloading will fix all of that. On reload, though, we need to clear our parent, since we may not have one any more. It will get reset if need be.
Re: problematic copier for JPEG figures?
Oops... I cannot reproduce it on the other machine, so I need to examine this problem more carefully before I report back. Regards, Yihui -- Yihui Xie Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, Jul 18, 2012 at 1:06 AM, Yihui Xie wrote: > Hi, > > I'm not sure anyone else can reproduce this weird behavior under LyX > 2.0.4 (Ubuntu): the tex code for jpeg figures seems to be wrong. > Suppose the jpeg file is foo.jpg; in the tex code exported from LyX it > will become this: > > \includegraphics{\string"0_path_to_foo\string".jpg, jpeg} > > pdflatex will write the text "jpeg jpeg" before the figure in the PDF > output. It turns out that LyX copied foo.jpg to the temp dir as > "0_path_to_foo.jpg, jpeg". I do not understand why this happens. PNG > figures are fine. > > Regards, > Yihui > -- > Yihui Xie > Phone: 515-294-2465 Web: http://yihui.name > Department of Statistics, Iowa State University > 2215 Snedecor Hall, Ames, IA
Re: Undo.cpp reports an error on trunk
On 07/18/2012 10:48 AM, Jean-Marc Lasgouttes wrote: Le 18/07/2012 16:35, Richard Heck a écrit : On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote: Le 13/07/2012 19:21, Richard Heck a écrit : This is why I propose to add a parameter to reload telling whether undo should be discarded. I just committed that change. This is an obvious candidate for branch (no risk, IMO). OK. Looks like you never backported this particular fix. If you decide to do it, I'll backport my patch too. Which thing didn't I backport? rh
Re: Undo.cpp reports an error on trunk
Le 18/07/2012 16:35, Richard Heck a écrit : On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote: Le 13/07/2012 19:21, Richard Heck a écrit : This is why I propose to add a parameter to reload telling whether undo should be discarded. I just committed that change. This is an obvious candidate for branch (no risk, IMO). OK. Looks like you never backported this particular fix. If you decide to do it, I'll backport my patch too. JMarc
Re: Undo.cpp reports an error on trunk
On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote: Le 13/07/2012 19:21, Richard Heck a écrit : This is why I propose to add a parameter to reload telling whether undo should be discarded. I just committed that change. This is an obvious candidate for branch (no risk, IMO). OK. rh
Re: Undo.cpp reports an error on trunk
On 07/18/2012 06:08 AM, Jean-Marc Lasgouttes wrote: Le 13/07/2012 19:21, Richard Heck a écrit : OTOH, it looks like doing a reload in after save-as is a bit harsh. Is the goal only to sanitize IncludeInset? It certainly wouldn't surprise me if there were something simpler we could do. It was definitely a big hammer, that commit. The primary goal was to deal with the fact that children, parents, etc, may no longer be where there are supposed to be. But the Buffer contains all kinds of pointers (e.g., in the TOC, in the reference cache, etc) that may point to children and the like. So I'm guessing there are other issues. Does it mean that LyX just crashes if I remove a file that is supposed to be here? How rude... I can't remember exactly what the crash was. But suppose you save the file to a new location, then you close what used to be a child buffer. The original file thinks that Buffer is still a child, and it didn't get notified of anything because it's not the parent any longer. Etc. Richard
Re: LyX, XeTeX, bidi and Hebrew
On Wed, Jul 18, 2012 at 11:09 AM, Guenter Milde wrote: > On 2012-07-16, Ronen Abravanel wrote: > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > These files produced directly by the GIT version of LyX. > > As you can see, the braces are the inverted in both the PDF and the TeX > > files. > > However, they are inverted in the source file too! > > * What do you get if the example is written as > > שלום (שלום) > > in LyX? > Just "Hello (Hello)" in hebrew In LyX it's שלום (שלום) > * How would you write the same in OpenOffice or some other "word > processor"? > If I *write* the same thing in a different word processor (OO, ms word or other bidi-supported WP) I get the brace proper. If I paste the tex-code into a word processor, it's inverted as in the PDF. > After all, this is rather a XeTeX vs. pdfLaTeX problem: what does an > internet recherche for "Hebrew polyglossia XeTeX" reveal? Did you also try > LuaTeX? > Never seen working LuaTeX in Hebrew. > > Günter > > Anyway, I fixed it (patch in my previews mail). The "bug" is in the "old" latex\latex export: the hebrew support in LaTeX was broken so it was fixed in LyX. now, XeTeX need to get proper text so LyX should produce proper unicode file. Ronen.
Re: Undo.cpp reports an error on trunk
Le 13/07/2012 19:21, Richard Heck a écrit : OTOH, it looks like doing a reload in after save-as is a bit harsh. Is the goal only to sanitize IncludeInset? It certainly wouldn't surprise me if there were something simpler we could do. It was definitely a big hammer, that commit. The primary goal was to deal with the fact that children, parents, etc, may no longer be where there are supposed to be. But the Buffer contains all kinds of pointers (e.g., in the TOC, in the reference cache, etc) that may point to children and the like. So I'm guessing there are other issues. Does it mean that LyX just crashes if I remove a file that is supposed to be here? How rude... JMarc
Re: Undo.cpp reports an error on trunk
Le 13/07/2012 19:21, Richard Heck a écrit : This is why I propose to add a parameter to reload telling whether undo should be discarded. I just committed that change. This is an obvious candidate for branch (no risk, IMO). JMarc
Re: [PATCH] LFUN_BUFFER_FORALL
Le 18/07/2012 06:39, Scott Kostyshak a écrit : From: Jean-Marc Lasgouttes [lasgout...@lyx.org] Sent: Sunday, July 15, 2012 5:14 PM >Moreover, this code should not be in GuiView, but in >GuiApplication, since the function is at application level. Attached is my attempt to move the code to GuiApplication. I am having trouble instantiating a GuiWorkArea. Here are the errors I get: GuiApplication.cpp: In member function ‘virtual void lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest&, lyx::DispatchResult&)’: GuiApplication.cpp:1633:8: error: invalid use of incomplete type ‘class lyx::frontend::GuiWorkArea’ In file included from GuiApplication.cpp:15:0: GuiApplication.h:41:7: error: forward declaration of ‘class lyx::frontend::GuiWorkArea’ Try to #include "GuiWorkArea.h" at the start of GuiApplication.cpp. I think that this patch also addresses the other points you raised. It begins to look very good. See below for comments. JMarc + case LFUN_BUFFER_FORALL: { + GuiView * cv = currentView(); What if currentView() is null? I propose to do an early return in this case. Or maybe this can happen when all buffers are hidden and requires finer codeing. I do not know whether this is only a theoretical possibility, this may happen when using client to do scripting. On the mac at least, LyX can be running witout having any open window. Unless you want to be very complete, it is probably enough right now to return early. I do not think I have seen "cv" used as the name of a GuiView. From a quick poll if the source, I suggest "gv" or "view". The good thing about using a known name is that it requires less effort for the reader of the code. + Buffer * const buf = &cv->currentBufferView()->buffer(); Do we have a bufferview when the LyX window is there but no buffer is open? + FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun); FuncRequest const funcToRun =... (constify and no capitalization of variable names) + dr.setMessage(bformat(_("%1$s%2$s"), msg, from_utf8(commandToRun))); + Buffer * const last = theBufferList().last(); + Buffer * b = theBufferList().first(); + Buffer * nextBuf = 0; + // We cannot use a for loop as the buffer list cycles. + while (true) { + if (b != last) + nextBuf = theBufferList().next(b); //get next now bc LFUN might close current + + bool const hidden = !(guiApp->currentView() && guiApp->currentView()->workArea(*b)); No need to use guiApp-> there. Are you using currentView() because cv could become invalid? If so, why do you use it below? BTW, what happens if several windows are open? It looks like you are not going to see whether the buffers on other windows are + if (hidden) { + if (processHidden) { + cv->setBuffer(b); + lyx::dispatch(FuncToRun); + GuiWorkArea * const wa = cv->currentWorkArea(); + wa->view().hideWorkArea(wa); I am not sure that the intermediate wa variable is useful here. + } + } + + else { + if (processVisible) { else if (processvisible) { ...
Re: LyX, XeTeX, bidi and Hebrew
On 2012-07-16, Ronen Abravanel wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > These files produced directly by the GIT version of LyX. > As you can see, the braces are the inverted in both the PDF and the TeX > files. However, they are inverted in the source file too! * What do you get if the example is written as שלום (שלום) in LyX? * How would you write the same in OpenOffice or some other "word processor"? After all, this is rather a XeTeX vs. pdfLaTeX problem: what does an internet recherche for "Hebrew polyglossia XeTeX" reveal? Did you also try LuaTeX? Günter