questions regarding the minted listings support

[Uwe Stöhr]

Hi Enrico,

you added as "ef" added info to the EmbeddedObjects manual regarding the 
minted listings package.


(Why "ef" and not a readable name? Please use real names because that 
makes life easier.)


I tried minted out but failed. I have the following problems:

1. You write in the note that one should add these preamble lines:
\usepackage{float}
\floatstyle{plaintop}
The package float is already loaded if the user uses a non-default float 
placement for the document. So shouldn't it be checked if this package 
is already loaded?.
Isn't \floatstyle dangerous because it will affect all following float 
definitions? I would therefore at leas add a hint to input these 2 lines 
as last thing of the preamble.


2. You write that
"requires additional software (the pygments python module) and the 
-shell-escape option for the LaTeX backend, which allows arbitrary code 
execution."
What does that mean? What is the pygments python module? and how do i 
connect it with LyX? What is the LaTeX backend and how do I apply the 
option -shell-escape to it?


thanks and regards
Uwe

Re: Can shell-escape take advantage of needauth framework?

[Christian Ridderström]

On 25 July 2017 at 01:30, Tommaso Cucinotta  wrote:

> On 18/07/2017 21:50, Christian Ridderström wrote:
>
>> I do not know how many KGB/CIA agents will be willing attend the 'hack
>> LyX' classes. How much is it worth on a spy resume ?
>>
>
> haha! something like that must have been said by someone in Redmond while
> coming out with this new brilliant and super-useful business-oriented
> automation feature called "Word Macro", before Melissa came out in 1999!
>

I'd be more interested in what people at Redmond said regarding their
design of the graphics format called Windows Metafile:
 https://en.wikipedia.org/wiki/Windows_Metafile_vulnerability
In short:
- The Windows Metafile format had a "feature" which allowed arbitrary
embedded code to be executed on affected computers without the permission
of their users.
- The feature won the 2007 Pwnie Award for "Mass 0wnage" and "Breaking the
Internet".
- Even a Unix-like system that uses Wine to emulate Windows, for example,
could be exploited
- The vulnerability is an inherent defect in the design of WMF files,
because the underlying architecture of such files includes features which
allow actual code to be executed whenever a WMF file opens

The last part kind of reminds me of Gnuplot. Up until Windows XP the
systems were pre-configured to allow WMF files to execute their code.

Anyway, I just thought it might be interesting to compare with WMF.

Personally, I wrote patent applications using LyX during one of my prior
> jobs in industry, and helped my colleagues into getting used to LyX,
> disregarding recommendations of my colleagues in that I should have used
> the "proper" .docx template... that can be conveniently edited using a much
> more secure program and OS?!?
>
> Btw, +1 on threat analysis, and np with the minefield, even simply talking
> about security risks is being a good thing for LyX, and a few mines could
> already be spotted :-)!
>

/Christian

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

[Christian Ridderström]

On 24 July 2017 at 23:20, Tommaso Cucinotta  wrote:

> On 23/07/2017 20:55, Christian Ridderström wrote:
>
>> Regarding setting something in the preference file manually: The only
>> thing I mind is that it adds a global state to LyX, as opposed to
>> starting LyX with some parameters. The global state would likely
>> affect e.g. testing.
>>
>
> the good thing is that we already have the -userdir command-line option
> that allows testing from a predictable initial state, doesn't it :-) ?
>

Good point, thanks!
/Christian



> (AFAICR, extensively used in autotests for advanced F).
>
> T.
>

Re: Any descriptions of the security aspects (related to needauth and shell-escape)?

[Christian Ridderström]

On 24 July 2017 at 23:27, Tommaso Cucinotta  wrote:
>
>
> I support the idea as well, and I'm interested in contributing to it.
>

I could help as well, at least with the outside view.


> As a starting point for the needauth stuff, I had put a recap of the
> problem and motivations within this TT:
>
>   http://www.lyx.org/trac/ticket/10481
>
> and, just as a reminder, the shell-escape was one of the mentioned
> use-cases, albeit not the very one under my hands at that moment.
>
> I'd suggest not to create a .lyx document, but rather start from a wiki
> page under
>
>   https://wiki.lyx.org/Devel/Devel
>
> with a recap of the current status and exchanged ideas, and pointers to
> the Trac TTs tracking TODOs which we agreed upon.
>

For me it doesn't matter so much where we place it.

IIRC, it's possible to password protect a wiki page. I'll see if I still
remember how to do that...
   tic=21:35, toc=21:42
Ok, not so bad. There's now this wiki page:
   http://wiki.lyx.org/Devel/SafetyAndSecurity

I'm sending the password separately to a bunch of developers, apologies for
forgetting some.

This doesn't mean I'm saying we have to, or should, use this page, I just
want us to have the option. And a wiki page might be a good place to start.
Oh... the protection of a wiki page is weak, think of it as stopping search
engines etc.
/Christian

Re: cmake and make install

[Cor Blom]

Op 25-07-17 om 20:49 schreef Scott Kostyshak:

On Fri, Jun 02, 2017 at 09:55:33AM +0200, Cor Blom wrote:

Op 01-06-17 om 12:34 schreef Kornel Benko:

(the "%cmake"  macro inheritis all kind of openSUSE settings).

Which ones?

Expanded it becomes this:

find . -name CMakeLists.txt -exec sed -i -re
'/^[[:blank:]]*[sS][eE][tT][[:blank:]]*\([[:blank:]]*(CMAKE_BUILD_TYPE|CMAKE_COLOR_MAKEFILE|CMAKE_INSTALL_PREFIX|CMAKE_VERBOSE_MAKEFILE).*\)/{s/^/#IGNORE
/}' '{}' +

Outch. What went wrong if not using this command?
I AM interested.
Specifically
CMAKE_VERBOSE_MAKEFILE will be reset with -DLYX_QUIET=ON
CMAKE_INSTALL_PREFIX will be set on the commandline



If I don't use openSUSE's preconfigured settings for cmake but define them
myself, the make install stage is running fine. Made me wonder why I didn't
do that in the first place. Thanks for the help.

Will later look into other suggestions made.


Cor, so the default call to CMake does work for you in the end?
I just want to check if there is anything we need to improve on our end.

Scott



Yes, as far as I can see it works fine. I've set up building regular 
snapshots on openSUSE [1] and it seems ok. Since then I have not looked 
into it a lot. I need to do that during the coming weeks, because I 
seriously consider switching the openSUSE packages (of which I am the 
maintainer) to cmake.


Thanks,

Cor

[1] https://build.opensuse.org/package/show/home:cornelisbb:lyx-unstable/lyx

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Tue, Jul 25, 2017 at 11:11:36AM +0200, Pavel Sanda wrote:

> Scott Kostyshak wrote:
> > It did feel strange that the "OK" and "Apply" buttons were not enabled
> > when checking the "Allow running external programs" checkbox, but I got
> > used to it quickly.
> 
> Likely not feature but just forgotten connect with signal of box being 
> checked.

No, this was done by design. The status of this checkbox is not saved in
the document, so the document should not be marked as dirty.

-- 
Enrico

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Mon, Jul 24, 2017 at 11:05:42PM -0400, Scott Kostyshak wrote:
> 
> I think the following is unexpected:
> 
> Change a different document setting, e.g., "Synchronize with output".
> The buttons "OK" and "Apply" are enabled. Then click on "Allow running
> external programs". Notice that the "OK" and "Apply" buttons are
> disabled, because the settings were applied. I expected only the "Allow
> running external programs" setting to be instantly applied, and that the
> "Synchronize with output" would only be applied when I click on "OK" or
> "Apply".

Yes, I was aware of this glitch, which is addressed by the attached patch.

> It did feel strange that the "OK" and "Apply" buttons were not enabled
> when checking the "Allow running external programs" checkbox, but I got
> used to it quickly.

This is by design. The checkbox status is not saved in the document but
in the session file, so the document should not be marked as dirty (as
it would be after "OK" or "Apply").

> I wonder if it would be more clear if we append to the current tooltip
> "(this setting is changed applied)".

The attached patch appends "(this setting is always applied immediately)".

> Regarding the message that's displayed when someone manually adds
> -shell-escape to a converter, I think we should point the user to more
> information so that they can learn how to use the built-in LyX feature.
> 
> Where is the appropriate place in our documentation for this feature?
> 
> Similarly, we should point the user to the relevant information for the
> minted example files.

Yes, many improvements are possible with a more little time at hand.
I am also investigating the possibility of attaching a context menu to
the red icon in the status bar.

-- 
Enrico
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index a9cc619060..d7e827fc2a 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -55,6 +55,7 @@
 #include "ParagraphParameters.h"
 #include "ParIterator.h"
 #include "PDFOptions.h"
+#include "Session.h"
 #include "SpellChecker.h"
 #include "sgml.h"
 #include "texstream.h"
@@ -980,6 +981,8 @@ int Buffer::readHeader(Lexer & lex)
errorList.push_back(ErrorItem(_("Document header error"), s));
}
 
+   params().shell_escape = 
theSession().shellescapeFiles().find(absFileName());
+
params().makeDocumentClass();
 
return unknown_tokens;
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 22e84778fe..c16c308c21 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -459,6 +459,7 @@ BufferParams::BufferParams()
html_css_as_file = false;
display_pixel_ratio = 1.0;
 
+   shell_escape = false;
output_sync = false;
use_refstyle = true;
use_minted = false;
diff --git a/src/BufferParams.h b/src/BufferParams.h
index c20601e2ac..bc5c10d194 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -535,6 +535,8 @@ public:
std::string html_latex_end;
///
bool html_css_as_file;
+   /// allow the LaTeX backend to run external programs
+   bool shell_escape;
/// generate output usable for reverse/forward search
bool output_sync;
/// custom LaTeX macro from user instead our own
diff --git a/src/Converter.cpp b/src/Converter.cpp
index 489f5df439..c9bce7f2db 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -279,20 +279,52 @@ OutputParams::FLAVOR 
Converters::getFlavor(Graph::EdgePath const & path,
 }
 
 
-bool Converters::checkAuth(Converter const & conv, string const & doc_fname)
+bool Converters::checkAuth(Converter const & conv, string const & doc_fname,
+  bool use_shell_escape)
 {
-   if (!conv.need_auth())
+   string conv_command = conv.command();
+   bool const has_shell_escape = contains(conv_command, "-shell-escape")
+   || contains(conv_command, "-enable-write18");
+   if (conv.latex() && has_shell_escape && !use_shell_escape) {
+   docstring const shellescape_warning =
+ bformat(_("The following LaTeX backend has been "
+   "configured to allow execution of external programs "
+   "for any document:"
+   "%1$s"
+   "This is a dangerous configuration. Please, "
+   "consider using the support offered by LyX for "
+   "allowing this privilege only to documents that "
+   "actually need it, instead."),
+   from_utf8(conv_command));
+   frontend::Alert::error(_("Security Warning"),
+   shellescape_warning , false);
+   } else if (!conv.latex())
+   use_shell_escape = false;
+   if (!conv.need_auth() && !use_shell_escape)
return true;
-   const docstring security_warning = bformat(
- _("The requested operation requires the use of a converter 

Re: cmake and make install

[Scott Kostyshak]

On Fri, Jun 02, 2017 at 09:55:33AM +0200, Cor Blom wrote:
> Op 01-06-17 om 12:34 schreef Kornel Benko:
> > > > > (the "%cmake"  macro inheritis all kind of openSUSE settings).
> > > > Which ones?
> > > Expanded it becomes this:
> > > 
> > > find . -name CMakeLists.txt -exec sed -i -re
> > > '/^[[:blank:]]*[sS][eE][tT][[:blank:]]*\([[:blank:]]*(CMAKE_BUILD_TYPE|CMAKE_COLOR_MAKEFILE|CMAKE_INSTALL_PREFIX|CMAKE_VERBOSE_MAKEFILE).*\)/{s/^/#IGNORE
> > > /}' '{}' +
> > Outch. What went wrong if not using this command?
> > I AM interested.
> > Specifically
> > CMAKE_VERBOSE_MAKEFILE will be reset with -DLYX_QUIET=ON
> > CMAKE_INSTALL_PREFIX will be set on the commandline
> > 
> 
> If I don't use openSUSE's preconfigured settings for cmake but define them
> myself, the make install stage is running fine. Made me wonder why I didn't
> do that in the first place. Thanks for the help.
> 
> Will later look into other suggestions made.

Cor, so the default call to CMake does work for you in the end?
I just want to check if there is anything we need to improve on our end.

Scott

alpha beta lyx-formats and devel versions of the docs

[mn]

The latest publicly available binaries are for alpha1-1.
The latest changes to the docs are format 544, and none of the versions
I have installed can read or convert them.

Now, say I have spotted errors or improvements in or for them, like
latest UserGuide.de.lyx:

26812selbst) Formate für alle verfügbarren Typen von Verweisen
vordefiniert.

How to proceed?

Proposal:
– more intermediate alphas, betas, at least in sync with the current
file-format.

greetings
Mike

Re: [LyX/master] We have new translation which slipped through the cracks.

[Scott Kostyshak]

On Tue, Jul 25, 2017 at 10:35:52AM +0200, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > > > We have new translation which slipped through the cracks.
> > > 
> > > Scott, I am sorry I did not catch that before.
> > 
> > I imagine this was my responsibility, actually. What command did you run
> > to make the above commit? Was it the following?
> > 
> > make layouttranslations1
> 
> make ../lib/layouttranslations in po/ directory when you use autotools.
> You can check whether make layouttranslations1 of cmake produces the same
> (I hope it does).
> 
> And please do not commit changes to this file blindly, it needs careful
> review so that some changes are not just accidental (e.g. translator was
> not aware that we changed pdf output not just UI string...).

OK thanks for the info.

Scott


signature.asc
Description: PGP signature

UserGuide.lyx suddenly not compilable for non-tex-fonts

[Kornel Benko]

Problems are missing glyphs
U+3008 ... U+300F
used for special quotes. Using tex-fonts they are emulated with math symbols.
(Seen in German and English version)

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Just a check: Ok with Qt-code in e.g. src/support/?

[Richard Heck]

On 07/25/2017 01:07 AM, Christian Ridderström wrote:
> Hi,
>
> This is just a check. A long time ago LyX had two frontends, i.e. not
> only Qt. Back then I assume the Qt-code was supposed to stay under
> src/frontends/qt4/.
>
> I just noticed some Qt code in e.g. src/support/FileMonitor.h, so I
> just wanted to check that we now are ok with Qt-code in e.g.
> /src/support/?

Yes.

Richard

Re: Can shell-escape take advantage of needauth framework?

[Tommaso Cucinotta]

On 25/07/2017 11:10, Pavel Sanda wrote:

1. No "needauth" preferences (do not allow needauth from being disabled).


instead of this, why don't we put some more stress on the action of disabling the 
"Use needauth option", e.g., the attached patch ?

Some nice text would have to be properly formulated of course...

Also, the "Use needauth option" checkbox label we have now could be reworded to 
smth like
"needauth converters need user permission", or
"ask user permission before running needauth converters", or
"don't run needauth converters without user's consent"
...

The forbid vs enable needauth of the left checkbox sounds ambiguous/confusing 
w.r.t. the use vs don't use needauth we have on the right checkbox.

T.


2. The dialog has a checkbox "I have read the above and I understand the
consequences", unchecked by default, which one has to check before
clicking "allow" or "always allow for the document". This checkbox is
remembered per-user (this replaces the "forbid use of needauth" option).
3. For command-line only (without GUI), have a command-line options
--needauth=[never(default)|always|ask].


I am not sure I understood this proposal, but if by 1&2 you mean
to replace "Forbid.." checkbox by unchecked "I have read...",
then I have no problem with it. (Though if we wanted to make it scary
it should contain words like "Warning" or "Dangerous".)

Ask Christian about the string, he seemed to be the main critic of UI...

Pavel



diff --git a/src/frontends/qt4/GuiPrefs.cpp b/src/frontends/qt4/GuiPrefs.cpp
index 5f2f4740..d33cc0f8 100644
--- a/src/frontends/qt4/GuiPrefs.cpp
+++ b/src/frontends/qt4/GuiPrefs.cpp
@@ -1874,6 +1874,21 @@ void PrefConverters::on_needauthForbiddenCB_toggled(bool checked)
 }
 
 
+void PrefConverters::on_needauthCB_toggled(bool checked)
+{
+	if (checked)
+		return;
+
+	int ret = frontend::Alert::prompt(
+		_("SECURITY WARNING!"), _("Unchecking this option has the effect that potentially harmful converters would be run without asking your permission first. This is UNSAFE and NOT recommended, unless you know what you are doing. Are you sure you would like to proceed ? The recommended and safe answer is NO!"),
+		0, 1, _(""), _(""));
+	if (ret == 0) {
+		needauthCB->setChecked(true);
+		return;
+	}
+}
+
+
 /
 //
 // FormatValidator
diff --git a/src/frontends/qt4/GuiPrefs.h b/src/frontends/qt4/GuiPrefs.h
index 3b6ff604..8f43a37e 100644
--- a/src/frontends/qt4/GuiPrefs.h
+++ b/src/frontends/qt4/GuiPrefs.h
@@ -338,6 +338,7 @@ private Q_SLOTS:
 	void changeConverter();
 	void on_cacheCB_stateChanged(int state);
 	void on_needauthForbiddenCB_toggled(bool);
+	void on_needauthCB_toggled(bool);
 
 private:
 	void updateButtons();

Question for Guillaume about b30f8d3c and GuiFontMetrics::countExpanders

[Jean-Marc Lasgouttes]

Hi Guillaume,

The commit log for b30f8d3c says: " CountExpanders() is moved to 
FontMetrics to fix a discrepancy with the duplicate implementation from 
598f7e4a."


I interpret that to mean that countExpanders() should be available in 
GuiPainter too, right?


OTOH, countExpanders is basically a plain function and it seems weird to 
require a FontMetrics object to compute it.


Is there a reason why it is not a free standing function somewhere in 
support/ ?


JMarc

Re: [LyX features/properpaint] Fix caret painting

[Jean-Marc Lasgouttes]

Le 25/07/2017 à 11:37, Pavel Sanda a écrit :

Preliminary testing shows that the performance of pressing cursor down
repeatedly is the same, but the performance of Page Down is much better.


Is this supposed to change only perf of going down or it also affects just
going through the text (left/right arrow) without painting new lines?


I don't know, try it :) The slowness you are experiencing is a bit 
mysterious to me.


JMarc

Re: [LyX features/properpaint] Cleanup and simplify WorkArea code

[Jean-Marc Lasgouttes]

Le 25/07/2017 à 11:33, Pavel Sanda a écrit :

Not sure how much strict you wanted to be about cursor/caret
but there were bunch of "cursors" left in the patch... P


Indeed :) I'll double check that.

JMarc

Re: [LyX features/properpaint] Fix caret painting

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 21/07/2017 ?? 23:31, Jean-Marc Lasgouttes a écrit :
>> The branch, properpaint, has been updated.
>> - Log -
>> commit de11aeb73b97ea6fd3c76d71aa027d5d7dc90f7d
>> Author: Jean-Marc Lasgouttes 
>> Date:   Thu Jul 20 23:31:05 2017 +0200
>>  Fix caret painting
>
> With this commit, the new painting scheme (without intermediate Pixmap) 
> seems to work. This has only been tested with Qt4 and input methods are 
> broken right now.
>
> Preliminary testing shows that the performance of pressing cursor down 
> repeatedly is the same, but the performance of Page Down is much better.

Is this supposed to change only perf of going down or it also affects just
going through the text (left/right arrow) without painting new lines?

Pavel

Re: [LyX features/properpaint] Cleanup and simplify WorkArea code

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> @@ -486,9 +469,9 @@ void GuiWorkArea::redraw(bool update_metrics)
>  
>   // update cursor position, because otherwise it has to wait until
>   // the blinking interval is over
> - if (d->cursor_visible_) {
> - d->hideCursor();
> - d->showCursor();
> + if (d->caret_visible_) {
> + d->hideCaret();
> + d->showCaret();
>   }

>   // In order to avoid bad surprise in the middle of an operation,
> - // we better stop the blinking cursor...
> - // the cursor gets restarted in GuiView::restartCursor()
> - stopBlinkingCursor();
> + // we better stop the blinking caret...
> + // the cursor gets restarted in GuiView::restartCaret()
> + stopBlinkingCaret();
>   guiApp->processKeySym(key, mod);

> @@ -548,7 +531,7 @@ void GuiWorkArea::Private::dispatch(FuncRequest const & 
> cmd)
>   // In order to avoid bad surprise in the middle of an operation, we 
> better stop
>   // the blinking cursor.
>   if (notJustMovingTheMouse)
> - p->stopBlinkingCursor();
> + p->stopBlinkingCaret();
>  
>   buffer_view_->mouseEventDispatch(cmd);
>  

> @@ -569,7 +552,7 @@ void GuiWorkArea::Private::dispatch(FuncRequest const & 
> cmd)
>   lyx_view_->clearMessage();
>  
>   // Show the cursor immediately after any operation
> - p->startBlinkingCursor();
> + p->startBlinkingCaret();

>   //int cur_x = buffer_view_->getPos(cur).x_;
>   // We may have decided to slide the cursor row so that cursor
>   // is visible.
> - p.x_ -= buffer_view_->horizScrollOffset();
> + point.x_ -= buffer_view_->horizScrollOffset();

> @@ -1277,7 +1233,7 @@ void GuiWorkArea::inputMethodEvent(QInputMethodEvent * 
> e)
>   // get attributes of input method cursor.
>   // cursor_pos : cursor position in preedit string.
>   size_t cursor_pos = 0;
> - bool cursor_is_visible = false;
> + bool caret_is_visible = false;
>   for (int i = 0; i != att.size(); ++i) {
>   if (att.at(i).type == QInputMethodEvent::Cursor) {
>   cursor_pos = att.at(i).start;

>   /// hide the visible cursor, if it is visible
> - void hideCursor();
> + void hideCaret();
>   /// show the cursor if it is not visible
> - void showCursor();
> + void showCaret();

> + /// is the cursor currently displayed
> + bool caret_visible_;


Not sure how much strict you wanted to be about cursor/caret
but there were bunch of "cursors" left in the patch... P

Re: Options for resolving the minted + shell-escape issue

[Pavel Sanda]

Scott Kostyshak wrote:
> It did feel strange that the "OK" and "Apply" buttons were not enabled
> when checking the "Allow running external programs" checkbox, but I got
> used to it quickly.

Likely not feature but just forgotten connect with signal of box being checked.
P

Re: Can shell-escape take advantage of needauth framework?

[Pavel Sanda]

Guillaume MM wrote:
> Not sure if what is being discussed is for 2.3 or for an ideal 
> implementation, but ideally what about:
>
> 1. No "needauth" preferences (do not allow needauth from being disabled).
> 2. The dialog has a checkbox "I have read the above and I understand the
> consequences", unchecked by default, which one has to check before
> clicking "allow" or "always allow for the document". This checkbox is
> remembered per-user (this replaces the "forbid use of needauth" option).
> 3. For command-line only (without GUI), have a command-line options
> --needauth=[never(default)|always|ask].

I am not sure I understood this proposal, but if by 1&2 you mean
to replace "Forbid.." checkbox by unchecked "I have read...",
then I have no problem with it. (Though if we wanted to make it scary
it should contain words like "Warning" or "Dangerous".)

Ask Christian about the string, he seemed to be the main critic of UI...

Pavel

Re: short report from LyX under Linux

[Pavel Sanda]

Paul A. Rubin wrote:
> On 07/24/2017 05:39 PM, Uwe Stöhr wrote:
> but Adobe Reader 9.5.5 is available for Ubuntu, Linux Mint, and maybe some 
> other Debian-based distributions. I assume it's not the latest version of 
> Reader, but it's fine for my purposes (which, admittedly, do not include 
> CAD output). Again, I'm not sure if it's available for Manjaro.

The binaries of linux Adobe Reader 9.5.5 are likely to work even now, the main
issue is security hazard, because it is unpatched for vulnerabilities for many
years. But if you use acroread only for your own CAD output it should be safe.

Pavel

Re: short report from LyX under Linux

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 24/07/2017 ?? 14:18, mn a écrit :
>> ??? Simplify UserGuide in regard to dependencies
>
> Indeed. Personally, I never use enumitem :) There is probably a good reason 
> why it is not in the main texlive distribution.

Ironically it was Uwe who disagreed to make UserGuide simpler WRT latex 
dependencies.

When it comes to Manajoro I do not think it shares repositories with Arch but
maintain its own repositories, so the dependency bug might be needed to file
with Manjaro.

Last but not least - it might be too late now, but choosing rolling
distribution might prove as PITA once you are not teenage with lot of time or
tech freak because constant updates will contantly break your system and will
need your attention.

Choosing LTS line of distributions like LTS (K)Ubuntu would pay much better
because once you tune your system, there is no need to touch it for next couple
years.

Pavel

Re: [LyX/master] Fixup the fixup d0acc3e57044: use editable()/isActive()

[Jean-Marc Lasgouttes]

Le 20/07/2017 à 15:13, Jürgen Spitzmüller a écrit :

Am Donnerstag, den 20.07.2017, 14:57 +0200 schrieb Jean-Marc
Lasgouttes:

Technically, insets with a dialog are also "editable".


No, now we say that they "have settings". The notion of editable is
really related to entering in the inset with a cursor.


I see. Didn't know. This strikes me like a rather idiosyncratic use of
"editing". I would prefer if the function name would be more clear
about what that means.


I seem to remember that a long time ago we had editable and "highly 
editable". The problem is that an inset can be both (think box inset), 
so it is better to have two names. HasSettings is a good choice, since 
the UI does not say "edit" but "settings".


JMarc

Re: [LyX/master] We have new translation which slipped through the cracks.

[Pavel Sanda]

Scott Kostyshak wrote:
> > > We have new translation which slipped through the cracks.
> > 
> > Scott, I am sorry I did not catch that before.
> 
> I imagine this was my responsibility, actually. What command did you run
> to make the above commit? Was it the following?
> 
> make layouttranslations1

make ../lib/layouttranslations in po/ directory when you use autotools.
You can check whether make layouttranslations1 of cmake produces the same
(I hope it does).

And please do not commit changes to this file blindly, it needs careful
review so that some changes are not just accidental (e.g. translator was
not aware that we changed pdf output not just UI string...).

Pavel

Re: [LyX/master] Overtake layout translations from fi.po, ja.po, zh_CN.po

[Pavel Sanda]

Jari-Matti Mäkelä wrote:
> Wed, 19 Jul 2017 13:41:17 +0200
> Pavel Sanda  wrote:
> 
> > Pavel Sanda wrote:
> > > Hi,
> > > thanks, for the clarifications!
> > > 
> > > I see you removed the "luettelo" parts which is supposedly "List"
> > > in your language. Are you sure about that change?
> 
> Yes, the common convention is not to write that in the PDF. I'll refer
> to this as an official authority:
> 
> /usr/share/texmf-dist/tex/generic/babel-finnish/finnish.ldf

I see, that is surprising.

> from babel-finnish would work the best. BTW wouldn't it be easier to
> use that instead of hard coding the text in LyX?

We would like to avoid such hardcoding, but the strings we ask for
are not translated by babel (unless some new strings appeared in
new versions).

> > > If you have book with bunch of algorithm codes and you put
> > > somewhere into appendix list of those, they will be introduced by
> > > Algoritmit instead of Algoritmien luettelo. Was that intended?  
> > 
> > I just checked that all the "List" strings were recently checked by
> > Martin Vermeer, so I think it was actually meant to be with
> > "luettelo". (?)
> 
> I might have messed up some things when writing the
> translations for the GUI. I feel the word 'luettelo/lista' might
> clarify things in the GUI, but then again the printed version should
> not show those. If both need to display the same, it might be
> clearer to use the print version for both.

Yes, Ok then.

> If they need different names, I'd use 'Kaavio / kaaviot' for
> chart/charts and 'Graafi / graafit' or 'Diagrammi / diagrammit' for
> some nonconventional graph/graphs. 'Kuvaaja' is just a synonym for
> 'kaavio'. I checked the translations and most presentations are called
> chart <-> kaavio. That word covers most of the graphs/charts out there.

Lets stay with kaavio then.
> 
> > > Graphs/Chart/Scheme are for papers written in layout for American
> > > Chemical Society and apparently they don't even care to show Graph
> > > example in their demo
> > > ( http://mirrors.ctan.org/macros/latex/contrib/achemso/achemso-demo.pdf
> > > ) so I think this particular tranaslation is not that important. 
> > > > > Apparently this is related to chemistry? Is the 'scheme' like
> > > > > 'Chemical equation', 'structural formula' or something else?
> > > > > It's hard to translate this without knowing the context.  
> > > 
> > > Most likely they are your 'structural formula'. 
> 
> The word for that would be 'Rakennekaava'. The word for 'chemical
> equation' is 'Reaktiokaava'. I'd imagine the chemists want to enumerate
> both, but don't know which one is more common if only one is supported.

Shrug. Kuvaus/Kuvausten luettelo was used, new version of yours Kuvaus/Kuvaukset
perhaps we can leave it in the old version until some chemist report complaint 
;)
> > > > > 
> > > > > "List of Listings"
> > > > > "List of Program Listing"
> > > > >   
> > > > > -> Ohjelmalistaukset  
> > > 
> > > They are program code.
> 
> Right, so the 'ohjelmalistaukset' sounds more reasonable. I'm a

Fine, so that's the version we have now.

FYI the current version for finish is now at
https://www.lyx.org/trac/browser/lyxgit/lib/layouttranslations?rev=5e2a9e32c47dc1325e475acc2a9c4dbf0336fc7d
in case you want to check we did not screw your advice.

Thanks for cooperation :)
Pavel