Re: r41206 - dictionaries/trunk/dicts
On 07/25/2018 01:47 PM, Jürgen Spitzmüller wrote: > Am Mittwoch, den 25.07.2018, 17:54 +0200 schrieb Jürgen Spitzmüller: >> Am Mittwoch, den 25.07.2018, 17:40 +0200 schrieb Pavel Sanda: >>> Git is unfortunately very bad system for storage of large binary >>> chunks, >>> compared to svn, all previous dicts will be locally stored on your >>> machine... >> Personally, I wouldn't mind. We do not update these files very often > Also note that the dictionaries are simple text files. For the time being, I will use Pavel's method, since it requires the least work (and does work). Longer term, we should perhaps move these somewhere better. Riki
Re: tex2lyx2.3 error
On 07/24/2018 02:03 PM, Richard Kimberly Heck wrote: > On 07/24/2018 11:25 AM, Scott Kostyshak wrote: >> On Tue, Jul 24, 2018 at 02:02:04PM +, Yu Jin wrote: >>> Is it just me or is the latex import completely broken? >>> Cant get it to import anything, even the most minimalistic documents. >>> It just says: >>> An error occurred while running: ..." >>> >>> Windows 2.3 Installer-005 >> Dear Yu Jin, >> >> I wonder if the bug you're seeing is the following, which will be fixed >> in LyX 2.3.1 (which will be released soon): >> >> https://www.lyx.org/trac/ticket/9139 > It's possible that this is due to changes in the location of binaries, or > their names, or some such. I had a hard time duplicating aspects of that. I > thought I'd fixed it all, but perhaps not. I'll check. The problem seems to be that there is a space in the directory name where LyX is installed. When I install into "LyX" rather than "LyX 2.3", it works fine. This seems like a bug in LyX itself, though I'll change this in the next installer. Riki
Re: r41206 - dictionaries/trunk/dicts
Am Mittwoch, den 25.07.2018, 17:54 +0200 schrieb Jürgen Spitzmüller: > Am Mittwoch, den 25.07.2018, 17:40 +0200 schrieb Pavel Sanda: > > Git is unfortunately very bad system for storage of large binary > > chunks, > > compared to svn, all previous dicts will be locally stored on your > > machine... > > Personally, I wouldn't mind. We do not update these files very often Also note that the dictionaries are simple text files. Jürgen > > Jürgen > > > > > Pavel signature.asc Description: This is a digitally signed message part
Re: Chinese (Simplified) translation for LyX
On Wed, Jul 25, 2018 at 08:06:03AM +, Jürgen Spitzmüller wrote: > Am Mittwoch, den 25.07.2018, 05:42 + schrieb 黄 克鲁: > > Dear LyX team, > > This is my work of a near-complete translation of LyX, with about > > 6900 entries translated, compared to about 3800 in the previous > > version. I hope it will be accepted in the next release. > > If any problems exist, contact me by this mail address. > > Dear Winfred > > Excellent, many thanks for this. +1 Winfred, that is great! Thanks for your help on that. I hope that more Chinese users will use LyX, thanks to your work. Best, Scott signature.asc Description: PGP signature
Re: [LyX/master] Fix austrian language code\n\nCandidate for stable.
On 07/25/2018 09:02 AM, Juergen Spitzmueller wrote: > commit b12ea3b7312d713e9987153c3555f56190ec6143 > Author: Juergen Spitzmueller > Date: Wed Jul 25 14:59:21 2018 +0200 > > Fix austrian language code\n\nCandidate for stable. OK for 2.3.1 or 2.3.2, as you wish. Riki
Re: Some (old?) math display problems
On 07/24/2018 06:31 PM, list_em...@icloud.com wrote: > LyX Version 2.3.0 > macOS 10.11.6 > > I’m back to writing again and I think I’m seeing some old friends that I > would rather not see. Maybe someone can suggest work-arounds. These relate to > math. > > When I enter one or more inline math things in a paragraph and then hit > RETURN to start a new paragraph, the Equations part of the Outline pane shows > an empty set of parentheses, (), for each inline math thing. Since they don’t > show any useful information, just (), I think this is not good. Oddly, > closing and re-opening the file makes them disappear from the panel. > > With Instant Preview on, each new numbered display equation, after rendering > to the “preview” state, is shown numbered as equation 1. Again, after closing > and re-opening the document, the previews show the correct equation number. > > Again with Instant Preview on, equation labels are shown in a box on their > own line below the equation. But if the label is more than a few characters > long and if my window or split is set to say 50% of the width of my laptop’s > screen, the label is clipped on the right, not displaying the entire label. I > notice a polite vertical line of red dots at the place that this happens but > the clipping is still present. Yet,there is a section of unused white space > to the left of the label—the label could be moved left and enjoy a much > larger area. Please file separate bug reports for each of these: https://www.lyx.org/trac/newticket. You might want to look through the existing math bugs first: https://www.lyx.org/trac/query?status=accepted=assigned=new=reopened=mathed=id=summary=status=type=priority=milestone=component=priority to make sure one's not already filed. If so, please feel free to add info. Riki
Re: Cross Reference dialog box is wider than my screen
On 07/24/2018 06:57 PM, list_em...@icloud.com wrote: > This is an old problem that I know I filed a ticket on years ago. The dialog > for Cross References attempts to display the entire path to the file in a > pop-up menu, regardless of how long the file path is. At the same time, in an > attempt to display the long pop-up menu item, the width of the dialog box is > adjusted, apparently without limit. The width can easily exceed the width of > the screen. The user can, with patience, drag the dialog box so that the > right edge is visible and can thus click on OK or Cancel or Apply, but > attempts to drag the right side of the box to the left and thus make the box > narrower, fail, as resizing is not allowed. This behavior persists even if > the current file path is not long, but a previously opened long file path > remains as a pop-up option. (Why do old file names live in this menu anyway?) > > This isn’t how things are supposed to work. A long string for a pop-up menu > item is supposed to be truncated and terminated with an ellipse, …, and > hovering over the truncated string should show a tooltip with the entire > string. Please file a bug report for this: https://www.lyx.org/trac/newticket Riki > > Jerry >
Re: r41206 - dictionaries/trunk/dicts
Am Mittwoch, den 25.07.2018, 17:40 +0200 schrieb Pavel Sanda: > Git is unfortunately very bad system for storage of large binary > chunks, > compared to svn, all previous dicts will be locally stored on your > machine... Personally, I wouldn't mind. We do not update these files very often Jürgen > > Pavel signature.asc Description: This is a digitally signed message part
Re: r41206 - dictionaries/trunk/dicts
Jürgen Spitzmüller wrote: > > Or you could copy the whole structure to our ftp, but again that > > would > > mean maintenance overhead we might not want. I would do it only in > > case > > the installer should download large chunks of dictionaries by > > default... > > I suggested to move the whole thing to git, and then use > https://git.lyx.org/. This seems faster and more stable than trac. Git is unfortunately very bad system for storage of large binary chunks, compared to svn, all previous dicts will be locally stored on your machine... Pavel
Re: Failing exports
Am Mittwoch, den 25.07.2018, 16:07 +0200 schrieb Kornel Benko: > I'd like to, but there is no specific author mentioned, (only > 'Elsevier Ltd'). I probably would have to subscribe some TeX list. The manual says: "Bugs, feature requests, suggestions and comments shall be mailed to ." Jürgen > > Kornel signature.asc Description: This is a digitally signed message part
Re: Failing exports
Am Mittwoch, 25. Juli 2018 15:38:37 CEST schrieb Jürgen Spitzmüller : > Am Mittwoch, den 25.07.2018, 15:30 +0200 schrieb Kornel Benko: > > BTW, this patch cures it for me. > > Yes, but we cannot ignore this rather genuine error message. IMHO this > error should not occur in the first place. Thus: most likely bug in the > class, please report to the authors. > > Jürgen > I'd like to, but there is no specific author mentioned, (only 'Elsevier Ltd'). I probably would have to subscribe some TeX list. Kornel signature.asc Description: This is a digitally signed message part.
[Fwd: Re: Chinese (Simplified) translation for LyX]
FYI. I asked him to resend to the list directly. Nonetheless I will commit his translations in order to have it in 2.3.1. Jürgen Weitergeleitete Nachricht Von: 黄 克鲁 An: Jürgen Spitzmüller Betreff: Re: Chinese (Simplified) translation for LyX Datum: Wed, 25 Jul 2018 08:25:01 + As you wish. I hereby grant permission to license any and all contributions I've made to LyX under the GNU GPL Version 2 or later. Winfred Huang 发自我的 iPhone > 在 2018年7月25日，16:06，Jürgen Spitzmüller 写道： > > I herby grant permission to license any and all contributions I've > made to LyX under the Gnu GPL version 2 or later. signature.asc Description: This is a digitally signed message part
Re: Failing exports
Am Mittwoch, den 25.07.2018, 15:30 +0200 schrieb Kornel Benko: > BTW, this patch cures it for me. Yes, but we cannot ignore this rather genuine error message. IMHO this error should not occur in the first place. Thus: most likely bug in the class, please report to the authors. Jürgen > > Kornel signature.asc Description: This is a digitally signed message part
Re: Failing exports
Am Mittwoch, 25. Juli 2018 15:15:34 CEST schrieb Jürgen Spitzmüller : > Am Mittwoch, den 25.07.2018, 15:09 +0200 schrieb Kornel Benko: > > Manually using pdflatex on exported .tex file has warnings and the > > tiltle in pdf is without the mark. > > But the second call to pdflatex creates the correct output and no > > warnings. > > But where does the error message come from? > > > So, from my POV, elsevier class needs a second latex run. How can we > > achieve this automatically? > > Can you post the logs of both manual runs, please? > > Jürgen > BTW, this patch cures it for me. Korneldiff --git a/src/LaTeX.cpp b/src/LaTeX.cpp index 0144e1c..afcfbbf 100644 --- a/src/LaTeX.cpp +++ b/src/LaTeX.cpp @@ -895,11 +895,13 @@ int LaTeX::scanLogFile(TeXErrors & terr) if (contains(desc, "Package babel Error: You haven't defined the language") || contains(desc, "Package babel Error: You haven't loaded the option") || contains(desc, - "Package babel Error: Unknown language")) + "Package babel Error: Unknown language") +|| contains(desc, + "Missing number, treated as zero")) retval |= ERROR_RERUN; // get the line number: int line = 0; sscanf(tmp.c_str(), "l.%d", ); // get the rest of the message: This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) (preloaded format=pdflatex 2018.7.5) 25 JUL 2018 15:28 entering extended mode restricted \write18 enabled. %&-line parsing enabled. **elsarticle.tex (./elsarticle.tex LaTeX2e <2018-04-01> patch level 5 (/usr9/local/texlive/2018/texmf-dist/tex/latex/elsarticle/elsarticle.cls Document Class: elsarticle 2018/06/08, 3.0: Elsevier Ltd \@bls=\dimen102 (/usr9/local/texlive/2018/texmf-dist/tex/latex/base/article.cls Document Class: article 2014/09/29 v1.4h Standard LaTeX document class (/usr9/local/texlive/2018/texmf-dist/tex/latex/base/size10.clo File: size10.clo 2014/09/29 v1.4h Standard LaTeX file (size option) ) \c@part=\count80 \c@section=\count81 \c@subsection=\count82 \c@subsubsection=\count83 \c@paragraph=\count84 \c@subparagraph=\count85 \c@figure=\count86 \c@table=\count87 \abovecaptionskip=\skip41 \belowcaptionskip=\skip42 \bibindent=\dimen103 ) (/usr9/local/texlive/2018/texmf-dist/tex/latex/graphics/graphicx.sty Package: graphicx 2017/06/01 v1.1a Enhanced LaTeX Graphics (DPC,SPQR) (/usr9/local/texlive/2018/texmf-dist/tex/latex/graphics/keyval.sty Package: keyval 2014/10/28 v1.15 key=value parser (DPC) \KV@toks@=\toks14 ) (/usr9/local/texlive/2018/texmf-dist/tex/latex/graphics/graphics.sty Package: graphics 2017/06/25 v1.2c Standard LaTeX Graphics (DPC,SPQR) (/usr9/local/texlive/2018/texmf-dist/tex/latex/graphics/trig.sty Package: trig 2016/01/03 v1.10 sin cos tan (DPC) ) (/usr9/local/texlive/2018/texmf-dist/tex/latex/graphics-cfg/graphics.cfg File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration ) Package graphics Info: Driver file: pdftex.def on input line 99. (/usr9/local/texlive/2018/texmf-dist/tex/latex/graphics-def/pdftex.def File: pdftex.def 2018/01/08 v1.0l Graphics/color driver for pdftex )) \Gin@req@height=\dimen104 \Gin@req@width=\dimen105 ) \c@tnote=\count88 \c@fnote=\count89 \c@cnote=\count90 \c@ead=\count91 \c@author=\count92 \@eadauthor=\toks15 \c@affn=\count93 \absbox=\box26 \keybox=\box27 \Columnwidth=\dimen106 \space@left=\dimen107 \els@boxa=\box28 \els@boxb=\box29 \leftMargin=\dimen108 \@enLab=\toks16 \@sep=\skip43 \@@sep=\skip44 (/usr9/local/texlive/2018/texmf-dist/tex/latex/natbib/natbib.sty Package: natbib 2010/09/13 8.31b (PWD, AO) \bibhang=\skip45 \bibsep=\skip46 LaTeX Info: Redefining \cite on input line 694. \c@NAT@ctr=\count94 ) \splwrite=\write3 \openout3 = `elsarticle.spl'. \appnamewidth=\dimen109 ) (/usr9/local/texlive/2018/texmf-dist/tex/latex/base/fontenc.sty Package: fontenc 2017/04/05 v2.0i Standard LaTeX package (/usr9/local/texlive/2018/texmf-dist/tex/latex/base/t1enc.def File: t1enc.def 2017/04/05 v2.0i Standard LaTeX file LaTeX Font Info:Redeclaring font encoding T1 on input line 48. )) (/usr9/local/texlive/2018/texmf-dist/tex/latex/base/inputenc.sty Package: inputenc 2018/04/06 v1.3b Input encoding file \inpenc@prehook=\toks17 \inpenc@posthook=\toks18 (/usr9/local/texlive/2018/texmf-dist/tex/latex/base/latin9.def File: latin9.def 2018/04/06 v1.3b Input encoding file )) (/usr9/local/texlive/2018/texmf-dist/tex/latex/amscls/amsthm.sty Package: amsthm 2017/10/31 v2.20.4 \thm@style=\toks19 \thm@bodyfont=\toks20 \thm@headfont=\toks21 \thm@notefont=\toks22 \thm@headpunct=\toks23 \thm@preskip=\skip47 \thm@postskip=\skip48 \thm@headsep=\skip49 \dth@everypar=\toks24 LaTeX Info: Redefining \qed on input line 274. ) \c@thm=\count95 (/usr9/local/texlive/2018/texmf-dist/tex/generic/babel/babel.sty Package: babel 2018/06/05 3.22 The Babel package (/usr9/local/texlive/2018/texmf-dist/tex/generic/babel/switch.def File: switch.def 2018/06/05 3.22 Babel switching mechanism )
Re: Failing exports
Am Mittwoch, den 25.07.2018, 15:09 +0200 schrieb Kornel Benko: > Manually using pdflatex on exported .tex file has warnings and the > tiltle in pdf is without the mark. > But the second call to pdflatex creates the correct output and no > warnings. But where does the error message come from? > So, from my POV, elsevier class needs a second latex run. How can we > achieve this automatically? Can you post the logs of both manual runs, please? Jürgen > > Kornel signature.asc Description: This is a digitally signed message part
Re: Failing exports
Am Mittwoch, 25. Juli 2018 13:06:29 CEST schrieb Jürgen Spitzmüller
:
> Am Mittwoch, den 25.07.2018, 12:08 +0200 schrieb Kornel Benko:
> > Am Samstag, 21. Juli 2018 19:34:20 CEST schrieb Kornel Benko <
> > kor...@lyx.org>:
> > > templates/elsarticle fails because of some problem with
> > > \end{frontmatter}
> > > \end{frontmatter}
> > > {}
> > > A number should have been here; I inserted `0'.
> > > (If you can't figure out why I needed to see a number,
> > > look up `weird error' in the index to The TeXbook.)
> > >
> > >
> >
> > What about this one? I seem unable to find the reason.
>
> Seems related to the affiliation foot note. Maybe a bug in the class.
> Write a bug report to the author.
>
> Jürgen
>
Manually using pdflatex on exported .tex file has warnings and the tiltle in
pdf is without the mark.
But the second call to pdflatex creates the correct output and no warnings.
So, from my POV, elsevier class needs a second latex run. How can we achieve
this automatically?
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: [LyX/master] Amend 79cf3f5ec10
Am Mittwoch, den 25.07.2018, 13:56 +0200 schrieb Jean-Marc Lasgouttes:
> > Anyway, I am currently looking into a more general solution wrt
> > #5348.
>
> Great.
Here is it. What this does, is:
* Use the context language of the info inset (rather than the buffer
language), and translate strings accordingly
* For menu and shortcuts, use the Gui language instead
* Actually care that all translatable strings end in po (this wasn't
the case).
Remaining glitch: When selecting an Info Inset and changing the
language, the effect in the workarea is only shown after buffe reload
or a change in the inset's settings. A buffer update missing, but I
can't see where.
What do you think?
Jürgen
>
> JMarc
diff --git a/src/Language.cpp b/src/Language.cpp
index 8110c17401..d7bcbd3c58 100644
--- a/src/Language.cpp
+++ b/src/Language.cpp
@@ -375,6 +375,26 @@ Match match(string const & code, Language const & lang)
} // namespace
+
+Language const * Languages::getFromCode(string const & code) const
+{
+ LanguageList::const_iterator const lbeg = languagelist.begin();
+ LanguageList::const_iterator const lend = languagelist.end();
+ // Try for exact match first
+ for (LanguageList::const_iterator lit = lbeg; lit != lend; ++lit) {
+ if (match(code, lit->second) == ExactMatch)
+ return >second;
+ }
+ // If not found, look for lang prefix (without country) instead
+ for (LanguageList::const_iterator lit = lbeg; lit != lend; ++lit) {
+ if (match(code, lit->second) == ApproximateMatch)
+ return >second;
+ }
+ LYXERR0("Unknown language `" + code + "'");
+ return 0;
+}
+
+
void Languages::readLayoutTranslations(support::FileName const & filename)
{
Lexer lex;
@@ -395,13 +415,7 @@ void Languages::readLayoutTranslations(support::FileName const & filename)
if (!lex.next(true))
break;
string const code = lex.getString();
- bool found = false;
- for (LanguageList::iterator lit = lbeg; lit != lend; ++lit) {
- if (match(code, lit->second) != NoMatch) {
-found = true;
-break;
- }
- }
+ bool found = getFromCode(code);
if (!found) {
lex.printError("Unknown language `" + code + "'");
break;
diff --git a/src/Language.h b/src/Language.h
index d3f0e17139..9587d7987a 100644
--- a/src/Language.h
+++ b/src/Language.h
@@ -162,6 +162,8 @@ public:
///
void read(support::FileName const & filename);
///
+ Language const * getFromCode(std::string const & code) const;
+ ///
void readLayoutTranslations(support::FileName const & filename);
///
Language const * getLanguage(std::string const & language) const;
diff --git a/src/insets/InsetInfo.cpp b/src/insets/InsetInfo.cpp
index 3cec4ee77d..e6776abe4a 100644
--- a/src/insets/InsetInfo.cpp
+++ b/src/insets/InsetInfo.cpp
@@ -15,6 +15,7 @@
#include "BufferParams.h"
#include "BufferView.h"
#include "CutAndPaste.h"
+#include "Font.h"
#include "FuncRequest.h"
#include "FuncStatus.h"
#include "InsetGraphics.h"
@@ -28,6 +29,8 @@
#include "LyXRC.h"
#include "LyXVC.h"
#include "Lexer.h"
+#include "Paragraph.h"
+#include "ParIterator.h"
#include "ParagraphParameters.h"
#include "version.h"
@@ -41,6 +44,7 @@
#include "support/FileName.h"
#include "support/filetools.h"
#include "support/gettext.h"
+#include "support/Messages.h"
#include "support/lstrings.h"
#include "support/qstring_helpers.h"
#include "support/Translator.h"
@@ -284,22 +288,29 @@ void InsetInfo::setInfo(string const & name)
}
-void InsetInfo::error(string const & err)
+void InsetInfo::error(docstring const & err, Language const * lang)
{
- setText(bformat(_(err), from_utf8(name_)),
- Font(inherit_font, buffer().params().language), false);
+ setText(bformat(translateIfPossible(err, lang->code()), from_utf8(name_)),
+ Font(inherit_font, lang), false);
}
-void InsetInfo::setText(docstring const & str)
+void InsetInfo::info(docstring const & err, Language const * lang)
{
- setText(str, Font(inherit_font, buffer().params().language), false);
+ setText(translateIfPossible(err, lang->code()),
+ Font(inherit_font, lang), false);
+}
+
+
+void InsetInfo::setText(docstring const & str, Language const * lang)
+{
+ setText(str, Font(inherit_font, lang), false);
}
bool InsetInfo::forceLTR() const
{
- return !buffer().params().language->rightToLeft() || force_ltr_;
+ return force_ltr_;
}
@@ -313,11 +324,18 @@ void InsetInfo::updateBuffer(ParIterator const & it, UpdateType utype) {
return;
BufferParams const & bp = buffer().params();
-
- force_ltr_ = false;
+ Language const * lang = it.paragraph().getFontSettings(bp, it.pos()).language();
+ Language const * tryguilang = languages.getFromCode(Messages::guiLanguage());
+ // Some info insets use the language of the GUI (if available)
+ Language const * guilang = tryguilang ? tryguilang : lang;
+
+ force_ltr_ = !lang->rightToLeft();
+ // This is just to get the string into the po files
+ docstring gui;
switch (type_) {
case UNKNOWN_INFO:
- error("Unknown Info: %1$s");
+ gui = _("Unknown Info!");
+
Re: [LyX/master] Amend 79cf3f5ec10
Le 25/07/2018 à 13:40, Jürgen Spitzmüller a écrit : Am Mittwoch, den 25.07.2018, 12:16 +0200 schrieb Jean-Marc Lasgouttes: Le 25/07/2018 à 11:42, Juergen Spitzmueller a écrit : commit d1ec35a0dc839ddc27caebed75dd71e60cc6764f Author: Juergen Spitzmueller Date: Wed Jul 25 11:38:56 2018 +0200 Amend 79cf3f5ec10 Some InfoInsets have to be LTR always. Why don't you test for type_ == SHORTCUT_INFO or SHORTCUTS_INFO in forceLTR() instead of introducing this boolean? because we use localized strings if the action is unknown or no binding exists, and this string can be RTL. I see. So you could actually do force_ltr_ = bp.language->rightToLeft() ; in InsetInfo::updateBuffer(). Anyway, I am currently looking into a more general solution wrt #5348. Great. JMarc
Re: [LyX/master] Amend 79cf3f5ec10
Am Mittwoch, den 25.07.2018, 12:16 +0200 schrieb Jean-Marc Lasgouttes: > Le 25/07/2018 à 11:42, Juergen Spitzmueller a écrit : > > commit d1ec35a0dc839ddc27caebed75dd71e60cc6764f > > Author: Juergen Spitzmueller > > Date: Wed Jul 25 11:38:56 2018 +0200 > > > > Amend 79cf3f5ec10 > > > > Some InfoInsets have to be LTR always. > > Why don't you test for type_ == SHORTCUT_INFO or SHORTCUTS_INFO in > forceLTR() instead of introducing this boolean? because we use localized strings if the action is unknown or no binding exists, and this string can be RTL. Anyway, I am currently looking into a more general solution wrt #5348. Jürgen signature.asc Description: This is a digitally signed message part
Re: r41206 - dictionaries/trunk/dicts
Am Mittwoch, den 25.07.2018, 13:09 +0200 schrieb Pavel Sanda: > Richard Kimberly Heck wrote: > > No, not at the moment, though it should. Uwe's installer uses his > > own > > sourceforge site, and for the moment I've duplicated that. Do you > > know > > what the correct URL would be for downloading these dictionaries > > from > > our own site? > > You need to use trac interface. The files can be downloaded via e.g.: > https://www.lyx.org/trac/browser/lyxsvn/dictionaries/trunk/thes/th_ru_RU_v2.dat?format=raw > > You might want to use specific revision bound to the time of release, > but that would mean checking/updating changeset number for each > release, e.g.: > > https://www.lyx.org/trac/export/41209/lyxsvn/dictionaries/trunk/thes/th_ru_RU_v2.dat > > Or you could copy the whole structure to our ftp, but again that > would > mean maintenance overhead we might not want. I would do it only in > case > the installer should download large chunks of dictionaries by > default... I suggested to move the whole thing to git, and then use https://git.lyx.org/. This seems faster and more stable than trac. Jürgen > > Pavel signature.asc Description: This is a digitally signed message part
Re: r41206 - dictionaries/trunk/dicts
Richard Kimberly Heck wrote: > No, not at the moment, though it should. Uwe's installer uses his own > sourceforge site, and for the moment I've duplicated that. Do you know > what the correct URL would be for downloading these dictionaries from > our own site? You need to use trac interface. The files can be downloaded via e.g.: https://www.lyx.org/trac/browser/lyxsvn/dictionaries/trunk/thes/th_ru_RU_v2.dat?format=raw You might want to use specific revision bound to the time of release, but that would mean checking/updating changeset number for each release, e.g.: https://www.lyx.org/trac/export/41209/lyxsvn/dictionaries/trunk/thes/th_ru_RU_v2.dat Or you could copy the whole structure to our ftp, but again that would mean maintenance overhead we might not want. I would do it only in case the installer should download large chunks of dictionaries by default... Pavel
Re: Failing exports
Am Mittwoch, den 25.07.2018, 12:08 +0200 schrieb Kornel Benko:
> Am Samstag, 21. Juli 2018 19:34:20 CEST schrieb Kornel Benko <
> kor...@lyx.org>:
> > templates/elsarticle fails because of some problem with
> > \end{frontmatter}
> > \end{frontmatter}
> > {}
> > A number should have been here; I inserted `0'.
> > (If you can't figure out why I needed to see a number,
> > look up `weird error' in the index to The TeXbook.)
> >
> >
>
> What about this one? I seem unable to find the reason.
Seems related to the affiliation foot note. Maybe a bug in the class.
Write a bug report to the author.
Jürgen
>
> Kornel
signature.asc
Description: This is a digitally signed message part
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On 25/07/2018 12:23, Jean-Marc Lasgouttes wrote: Le 25/07/2018 à 11:44, Daniel a écrit : ps. A further but more complicated version of (1) is to simulate a smaller thickness by using a 2px rule that consist of a black and half transparent black line. Well, typically, I do not intend to do complicate clever tricks... People will probably complain this this is blurry. I apologise for just making clever suggestions without making my hands dirty with programming. At the moment that is all I can do. Let me know if it isn't helpful. I am not going to spend a long amount of time on this right now anyway. What I propose is to revert my last patch for now. I leave for one month of vacation tonight anyway. I will only occasionally read e-mail and probably not provide code. Have a nice vacation! Daniel
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On 25/07/2018 12:30, Jean-Marc Lasgouttes wrote: Le 25/07/2018 à 11:40, Daniel a écrit : Even if you know what you are doing it can be helpful to have visual guides. I am sure you could do (or maybe you do) programming in a plain text editor. Still many people prefer editors that support highlighting. Why again does the thicker line that separates head and body of the table not help to get a better overview of the table? Call me an heretic, but sometimes I use several \midrule in a table. It did not occur to me that it was forbidden outside of header/footer separation. And I do not use \cmidrules in normal operation. The head/foot separation was only an example. There may be other ones. The main point was: the greater thickness is there indicate a special separation. Daniel
Re: [LyX/master] Draw top/bottom rules heavier for booktab
Le 25/07/2018 à 11:40, Daniel a écrit : Even if you know what you are doing it can be helpful to have visual guides. I am sure you could do (or maybe you do) programming in a plain text editor. Still many people prefer editors that support highlighting. Why again does the thicker line that separates head and body of the table not help to get a better overview of the table? Call me an heretic, but sometimes I use several \midrule in a table. It did not occur to me that it was forbidden outside of header/footer separation. And I do not use \cmidrules in normal operation. I don't see how a thicker line at the top and bottom of a table that *indicates* a formal table encourages people to use that style. In contrast a better separation in complex tables of the header and body and footer may do so. Hmm. I see. I guess we had different aims in mind. Yours was to distinguish formal from non-formal tables. Mine was to enhance readability and provide a structural indication of what the final table will look like (which in turn might encourage people using it). I am going to return to the previous version for now. We'll see in a month whether a mutiny in favor of bolder rules grows. JMarc
Re: [LyX/master] Draw top/bottom rules heavier for booktab
Le 25/07/2018 à 11:44, Daniel a écrit : ps. A further but more complicated version of (1) is to simulate a smaller thickness by using a 2px rule that consist of a black and half transparent black line. Well, typically, I do not intend to do complicate clever tricks... People will probably complain this this is blurry. I apologise for just making clever suggestions without making my hands dirty with programming. At the moment that is all I can do. Let me know if it isn't helpful. I am not going to spend a long amount of time on this right now anyway. What I propose is to revert my last patch for now. I leave for one month of vacation tonight anyway. I will only occasionally read e-mail and probably not provide code. JMarc
Re: Failing exports
Am Samstag, 21. Juli 2018 19:34:20 CEST schrieb Kornel Benko :
> templates/elsarticle fails because of some problem with \end{frontmatter}
> \end{frontmatter}
> {}
> A number should have been here; I inserted `0'.
> (If you can't figure out why I needed to see a number,
> look up `weird error' in the index to The TeXbook.)
>
>
What about this one? I seem unable to find the reason.
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On 25/07/2018 11:40, Daniel wrote: On 25/07/2018 10:37, Jean-Marc Lasgouttes wrote: Le 25/07/2018 à 09:08, Daniel a écrit : Thanks. I think it looks good. I prefer it. So we disagree ;) Unfortunately ;) Attached is a comparison with a PDF output (one with, roughly, the same table size and one with, roughly, the same font size). Note that when the table is larger in pdf, the rulles are thicker too (they are in em). This makes sense, but the thickness here is to be compared to the 'blackness' of the font (I am not sure of my typographical technical terms). I still think that the top/bottom lines are too thick. I tend to disagree. But my two alternative suggestions (1) and (2) would cover this without giving up head/body separation. I take it that the thicker first and second lines are just eye cady while the thicker line(s) in between fulfill the more important function of making it easier to distinguish between, for example, the head and the foot of the table and the body. The thick top/bottom lines convey that the table is a formal table. It is not eye candy, it is a WYSYWYM indicator. The fact that incomplete les are thinner *is* eye candy. Only people doing complicated tables care about it, and these people are supposed to know what they are doing. Even if you know what you are doing it can be helpful to have visual guides. I am sure you could do (or maybe you do) programming in a plain text editor. Still many people prefer editors that support highlighting. Why again does the thicker line that separates head and body of the table not help to get a better overview of the table? I want to do something that encourages people to use formal tables (there were talks about setting it as default), but do not attract too much the eye. Having a thinner line for incomplete lines would be eye candy IMO. But I am not a specialist in formal tables. I don't see how a thicker line at the top and bottom of a table that *indicates* a formal table encourages people to use that style. In contrast a better separation in complex tables of the header and body and footer may do so. Anyway, here are a couple of alternatives with some reason for it: (1) Make all thicker lines the same width (2px). Reason: The thicker first and second line are not confused with other lines because of their special location. What do you call first and second? I (3), it looks like top/bottom, but here ?? Yes, I mean top and bottom. The idea is: Having a slightly thicker top/bottom rule than the head separation rule is more of an eye candy. It would not hinder readability if all thick rules (top, bottom, header separator) had the same thickness (2px). (2) Have only the lines in between thick (2px). Reason: The thicker first and second lines are only eye candy anyway. ??? Not sure what the question is here. So I hope my further explanation helps. Above I explained why I think that concerning readability of the table the top/bottom rules are eye candy because they don't help separating anything (like head from body). So the thought is: leave them at normal thickness (1px) instead. (3) Have only the first and second line thick (2px), as in your first version. Reason: The thicker first and second lines are there only to indicate that the table is formal/a booktab. That was precisely my point. I see. I guess we had different aims in mind. Yours was to distinguish formal from non-formal tables. Mine was to enhance readability and provide a structural indication of what the final table will look like (which in turn might encourage people using it). ps. A further but more complicated version of (1) is to simulate a smaller thickness by using a 2px rule that consist of a black and half transparent black line. I apologise for just making clever suggestions without making my hands dirty with programming. At the moment that is all I can do. Let me know if it isn't helpful. Daniel
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On 25/07/2018 10:37, Jean-Marc Lasgouttes wrote: Le 25/07/2018 à 09:08, Daniel a écrit : Thanks. I think it looks good. I prefer it. So we disagree ;) Unfortunately ;) Attached is a comparison with a PDF output (one with, roughly, the same table size and one with, roughly, the same font size). Note that when the table is larger in pdf, the rulles are thicker too (they are in em). This makes sense, but the thickness here is to be compared to the 'blackness' of the font (I am not sure of my typographical technical terms). I still think that the top/bottom lines are too thick. I tend to disagree. But my two alternative suggestions (1) and (2) would cover this without giving up head/body separation. I take it that the thicker first and second lines are just eye cady while the thicker line(s) in between fulfill the more important function of making it easier to distinguish between, for example, the head and the foot of the table and the body. The thick top/bottom lines convey that the table is a formal table. It is not eye candy, it is a WYSYWYM indicator. The fact that incomplete les are thinner *is* eye candy. Only people doing complicated tables care about it, and these people are supposed to know what they are doing. Even if you know what you are doing it can be helpful to have visual guides. I am sure you could do (or maybe you do) programming in a plain text editor. Still many people prefer editors that support highlighting. Why again does the thicker line that separates head and body of the table not help to get a better overview of the table? I want to do something that encourages people to use formal tables (there were talks about setting it as default), but do not attract too much the eye. Having a thinner line for incomplete lines would be eye candy IMO. But I am not a specialist in formal tables. I don't see how a thicker line at the top and bottom of a table that *indicates* a formal table encourages people to use that style. In contrast a better separation in complex tables of the header and body and footer may do so. Anyway, here are a couple of alternatives with some reason for it: (1) Make all thicker lines the same width (2px). Reason: The thicker first and second line are not confused with other lines because of their special location. What do you call first and second? I (3), it looks like top/bottom, but here ?? Yes, I mean top and bottom. The idea is: Having a slightly thicker top/bottom rule than the head separation rule is more of an eye candy. It would not hinder readability if all thick rules (top, bottom, header separator) had the same thickness (2px). (2) Have only the lines in between thick (2px). Reason: The thicker first and second lines are only eye candy anyway. ??? Not sure what the question is here. So I hope my further explanation helps. Above I explained why I think that concerning readability of the table the top/bottom rules are eye candy because they don't help separating anything (like head from body). So the thought is: leave them at normal thickness (1px) instead. (3) Have only the first and second line thick (2px), as in your first version. Reason: The thicker first and second lines are there only to indicate that the table is formal/a booktab. That was precisely my point. I see. I guess we had different aims in mind. Yours was to distinguish formal from non-formal tables. Mine was to enhance readability and provide a structural indication of what the final table will look like (which in turn might encourage people using it). Daniel
Re: [LyX/master] Draw top/bottom rules heavier for booktab
Le 25/07/2018 à 09:08, Daniel a écrit : Thanks. I think it looks good. I prefer it. So we disagree ;) Attached is a comparison with a PDF output (one with, roughly, the same table size and one with, roughly, the same font size). Note that when the table is larger in pdf, the rulles are thicker too (they are in em). This makes sense, but the thickness here is to be compared to the 'blackness' of the font (I am not sure of my typographical technical terms). I still think that the top/bottom lines are too thick. I take it that the thicker first and second lines are just eye cady while the thicker line(s) in between fulfill the more important function of making it easier to distinguish between, for example, the head and the foot of the table and the body. The thick top/bottom lines convey that the table is a formal table. It is not eye candy, it is a WYSYWYM indicator. The fact that incomplete les are thinner *is* eye candy. Only people doing complicated tables care about it, and these people are supposed to know what they are doing. I want to do something that encourages people to use formal tables (there were talks about setting it as default), but do not attract too much the eye. Having a thinner line for incomplete lines would be eye candy IMO. But I am not a specialist in formal tables. Anyway, here are a couple of alternatives with some reason for it: (1) Make all thicker lines the same width (2px). Reason: The thicker first and second line are not confused with other lines because of their special location. What do you call first and second? I (3), it looks like top/bottom, but here ?? (2) Have only the lines in between thick (2px). Reason: The thicker first and second lines are only eye candy anyway. ??? (3) Have only the first and second line thick (2px), as in your first version. Reason: The thicker first and second lines are there only to indicate that the table is formal/a booktab. That was precisely my point. JMarc
Re: Chinese (Simplified) translation for LyX
Am Mittwoch, den 25.07.2018, 05:42 + schrieb 黄 克鲁: > Dear LyX team, > This is my work of a near-complete translation of LyX, with about > 6900 entries translated, compared to about 3800 in the previous > version. I hope it will be accepted in the next release. > If any problems exist, contact me by this mail address. Dear Winfred Excellent, many thanks for this. Before we can include it, can you please post a message to lyx-devel (just reply to this message will suffice), stating something such as: "I herby grant permission to license any and all contributions I've made to LyX under the Gnu GPL version 2 or later." Best Jürgen > Best regards, > Winfred Huang > 25/7/2018 signature.asc Description: This is a digitally signed message part
Re: Cross Reference dialog box is wider than my screen (2nd attempt, w/attachment)
Am Dienstag, den 24.07.2018, 16:05 -0700 schrieb list_em...@icloud.com: > This is an old problem that I know I filed a ticket on years ago. You remember which? > The dialog for Cross References attempts to display the entire path > to the file in a pop-up menu, regardless of how long the file path > is. At the same time, in an attempt to display the long pop-up menu > item, the width of the dialog box is adjusted, apparently without > limit. The width can easily exceed the width of the screen. The user > can, with patience, drag the dialog box so that the right edge is > visible and can thus click on OK or Cancel or Apply, but attempts to > drag the right side of the box to the left and thus make the box > narrower, fail, as resizing is not allowed. This behavior persists > even if the current file path is not long, but a previously opened > long file path remains as a pop-up option. Interesting. Here (Linux, LyX 2.3.1svn), the path is truncated. Which version of LyX is that? > (Why do old file names live in this menu anyway?) These are only all opened buffers (including those opened in "hidden" state). > This isn’t how things are supposed to work. A long string for a pop- > up menu item is supposed to be truncated and terminated with an > ellipse, …, and hovering over the truncated string should show a > tooltip with the entire string. I agree. Maybe some Mac-specific problem? Jürgen > > Jerry > > > signature.asc Description: This is a digitally signed message part
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On 24/07/2018 20:49, Jean-Marc Lasgouttes wrote: Le 24/07/2018 à 18:58, Daniel a écrit : Send an enjoyable lyx file... If I understood you correctly you offer to create a screenshot for me. Attached is the standard example from booktabs package (probably it will become more vegetarian friendly in a future version). Here is a screenshot at the default 150% zoom. I think that the bold line attracts too much the eye and is a hindrance for focusing on the contents of the document (typical issue with bold in typography). YMMV. Thanks. I think it looks good. I prefer it. Attached is a comparison with a PDF output (one with, roughly, the same table size and one with, roughly, the same font size). I take it that the thicker first and second lines are just eye cady while the thicker line(s) in between fulfill the more important function of making it easier to distinguish between, for example, the head and the foot of the table and the body. Anyway, here are a couple of alternatives with some reason for it: (1) Make all thicker lines the same width (2px). Reason: The thicker first and second line are not confused with other lines because of their special location. (2) Have only the lines in between thick (2px). Reason: The thicker first and second lines are only eye candy anyway. (3) Have only the first and second line thick (2px), as in your first version. Reason: The thicker first and second lines are there only to indicate that the table is formal/a booktab. Daniel
