Re: Outliner problem

[Andrew Parsloe]

On 5/12/2016 5:39 p.m., Scott Kostyshak wrote:

On Mon, Dec 05, 2016 at 02:27:50PM +1300, Andrew Parsloe wrote:

Working on two documents at once with different levels of headings reveals a
problem with the outliner. If doc1 has, say, 3 levels (chap., sec., subsec.)
and doc2 has none, then the slider indicating how many levels to display is
dominated by doc2. Setting the slider for doc1 to show 3 levels, then
switching to doc2 zeros it again. Switching back to doc1, it stays at the
zero setting. When one is constantly switching between the documents, this
becomes irritating. (I don't know what the "keep" checkbox is supposed to
do, but it certainly doesn't retain the doc1 setting.) It would be good if
the slider setting "stuck" to a document.

I experimented by adding a couple of heading levels to doc2. Switching
between the documents shows the slider remembers 2 levels now. The smaller
number of levels still dominates.


I would say create a bug report for this and specify the component
"outliner". I think there are several known fundamental problems with
the outliner, perhaps necessitating a big rewrite to work around some
issues. So if we have all the bugs up there, then when someone does
finally get annoyed enough to tackle the mess, there will not be a
shortage of information.

Scott


Ticket #10512.

Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: #10481: Hardening LyX against potential misuse

[Scott Kostyshak]

On Mon, Dec 05, 2016 at 08:53:58AM +0100, Tommaso Cucinotta wrote:

> With the "Converter Definitions" label now at the same highlight/logical level
> as "Converter File Cache" and "Security" ones, I think there is no more the
> confusionabout which options in the dialog are specific to a single converter.

I still think it is confusing. What do you think about Guillaume's idea
of placing the global options above the converter definitions?

Thanks again for your persistence and follow-up commits to improve
things.

Scott


signature.asc
Description: PGP signature

Re: cumbersome behavior when switching output-engines regarding inputenc

[Guenter Milde]

On 2016-12-05, mn wrote:
> On 05.12.16 09:36, Guenter Milde wrote:

>>> There might be some incorrect or unexpected behavior when
>>> switching output engines in LyX, because Xetex does not
>>> support input-encoding settings:
>>> To reproduce: Start a document,
>> ...
>>> Try to compile the document. It will complain that inputenc
>>> is not suitable for the chosen engine.

>> Not here. It just compiles.

> I just retook the steps I outlined above again and had the same
> error again.

 There must be something else in your document. Try with File>New
 and see whether this produces the error. If yes, send the
 document. If not, tell what else is needed.

>>> "Language Package: Always Babel" (a remnant default)

>> This is the real reason: Babel-Hebrew is not suited for Unicode
>> fonts.

> Aha.
> Which I thought of as taken care of by LyX, since this was a gui setting.

By default, LyX selects the correct language package depending on
"use-non-TeX fonts" and document language - this is with "langauge
package = auto". The other GUI settings are there to override LyX's
choice in case you have special requirements unknown to LyX. 

...

>> You must use Polyglossia with "non-TeX fonts" and Hebrew (In LyX,
>> setting language module to "auto" is recommended.)

> Which I will do from now on.
> Thanks for the heads up.


>>> one line in the preamble loading Minion Pro.

>> Actually, loading MinionPro with "use non-TeX fonts" is useless at
>> best and could be problematic. The package sets up 8-bit fonts.

> I was experimenting with the Xetex-engine I have to use apparently now.
> Comparing outputs and fonts and handling opposed to pdflatex.
> I was hoping on it to ignore my loading Minion in that way, since I need
> to do it that way for pdflatex as setting the Font to Minion via gui is
> mysteriously broken (and incomplete).

You can, however, wrap the call to Minion in a conditonal that does not load
the package if "fontspec" is loaded.

>> Most probabely, the content of the preamble does not matter, anything
>> exept an empty user preamble will do (see below).

>>> Source View for Format LyX displays "\inputencoding utf8" while set
>>> for default-output: XeTeX

>> I cannot reproduce this here.

>>> To be sure I attached a small file demoing the error as is.

>> This reveals one more precondition: Hebrew text in the file. Remove 
>> this and it should compile OK. Any text (even ASCII) set to "language
>> hebrew" should trigger the error (given the other preconditios), 
>> because then Babel-Hebrew loads inputenc.

> This pulled-in dependency was completely off-radar for me.


> Removing Hebrew text from the file still loads babel but compiles.

Yes, up-to-date Babel supports fontspec for many languages (including Greek
and Russian).

...

>>> Source View for Format LyX displays
>>> "\inputencoding utf8"
>>> while set for default-output: XeTeX

>> seems to indicate that you are using LyX 2.1 
...
> But version here is 2.2.2,

I still don't get this here:

   "\inputencoding utf8"

is an encoding-change command. 

Do you get this with utf-8 or with "language default"?

Is it causing the problem or solving it?

Where in the document does it occur? Can you give 3 lines of context?


> If babel is so problematic for these engines, should LyX not then ignore
> these babel settings (which I forced on for pdflatex)?

No, there are some languages that are only supported by Babel.

> I do not know how many other (babel)languages pull in inputenc?

Hard to say, even a grep in the *.ldf files will not help, as a language
definition file may load inpuenc or not depending on the font setting.

OTOH, LyX ships with a file "languages" that list for every language whether
it is supported by Babel and/or Polyglossia. This is used with the default
setting "auto" to determine the right package.


>> I wonder if you could trigger an: "\inputencoding undefined" error 
>> with your document and LyX version when removing the Hebrew text or
>> setting the language package to "auto" or "polyglossia".

>> In any case, I don't believe we should unhide the inputenc setting 
>> with "non-TeX fonts".

> Agreed.

> That gui setting just sent me on the wrong track to solving this.

But the hidden setting could have sent you back on track...

Günter

[PATCHES] is there a reason why I should not do that?

[Jean-Marc Lasgouttes]

Dear all,

The following pair of patches get rid of the setPosCache and setDimCache 
methods that have been added over the years all over the inset and 
mathed code. The idea is that these code are not needed, since the only 
callers of draw and metrics are either
* the drawing/metrics code in MathRow (for math) TextMetrics/RowPainter 
(for text)

* the metrics/draw methods of child classes of given inset.

The idea is that the cache should be set by the real caller of these 
methods, which is already done in today's code.


Is there something I am missing, or should I just push the code to 
master and fix the fallout (which should be small at worst, IIUC what is 
going on)?


JMarc
From c6bd7c1008cddc6cc9c729db57ac3a5524ed8133 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Mon, 5 Dec 2016 11:51:18 +0100
Subject: [PATCH 1/2] Get rid of Inset::setPosCache

This helper method is used to set the inset position cache at drawing
time. However this is already done by the drawing code itself
(MathRow::draw, RowPainter::paintInset), so that there is no need to
do this same work again in a different place.

This commit comes with a mild risk (it might be that some of these calls were
useful after all!), but all of this is fixable.
---
 src/insets/Inset.cpp   |9 -
 src/insets/Inset.h |2 --
 src/insets/InsetIPA.cpp|1 -
 src/insets/InsetPreview.cpp|1 -
 src/mathed/CommandInset.cpp|1 -
 src/mathed/InsetMathArray.cpp  |1 -
 src/mathed/InsetMathBig.cpp|1 -
 src/mathed/InsetMathBox.cpp|2 --
 src/mathed/InsetMathCases.cpp  |1 -
 src/mathed/InsetMathColor.cpp  |1 -
 src/mathed/InsetMathDecoration.cpp |1 -
 src/mathed/InsetMathDelim.cpp  |1 -
 src/mathed/InsetMathDiagram.cpp|1 -
 src/mathed/InsetMathDots.cpp   |1 -
 src/mathed/InsetMathFont.cpp   |1 -
 src/mathed/InsetMathFrac.cpp   |1 -
 src/mathed/InsetMathHull.cpp   |2 --
 src/mathed/InsetMathNest.cpp   |1 -
 src/mathed/InsetMathSplit.cpp  |1 -
 src/mathed/InsetMathXYMatrix.cpp   |1 -
 src/mathed/MathMacro.cpp   |1 -
 src/mathed/MathMacroArgument.cpp   |1 -
 src/mathed/MathMacroTemplate.cpp   |1 -
 23 files changed, 34 deletions(-)

diff --git a/src/insets/Inset.cpp b/src/insets/Inset.cpp
index 6e2e4a0..9c385b1 100644
--- a/src/insets/Inset.cpp
+++ b/src/insets/Inset.cpp
@@ -543,7 +543,6 @@ void Inset::drawMarkers(PainterInfo & pi, int x, int y) const
 	pi.pain.line(t, d - 3, t, d, pen_color);
 	pi.pain.line(x, d, x + 3, d, pen_color);
 	pi.pain.line(t - 3, d, t, d, pen_color);
-	setPosCache(pi, x, y);
 }
 
 
@@ -560,7 +559,6 @@ void Inset::drawMarkers2(PainterInfo & pi, int x, int y) const
 	pi.pain.line(t, a + 3, t, a, pen_color);
 	pi.pain.line(x, a, x + 3, a, pen_color);
 	pi.pain.line(t - 3, a, t, a, pen_color);
-	setPosCache(pi, x, y);
 }
 
 
@@ -621,13 +619,6 @@ ColorCode Inset::labelColor() const
 }
 
 
-void Inset::setPosCache(PainterInfo const & pi, int x, int y) const
-{
-	//LYXERR("Inset: set position cache to " << x << " " << y);
-	pi.base.bv->coordCache().insets().add(this, x, y);
-}
-
-
 void Inset::setDimCache(MetricsInfo const & mi, Dimension const & dim) const
 {
 	mi.base.bv->coordCache().insets().add(this, dim);
diff --git a/src/insets/Inset.h b/src/insets/Inset.h
index 48ad7be..e9937dc 100644
--- a/src/insets/Inset.h
+++ b/src/insets/Inset.h
@@ -211,8 +211,6 @@ public:
 	int xo(BufferView const & bv) const;
 	/// last drawn position for 'important' insets
 	int yo(BufferView const & bv) const;
-	/// set x/y drawing position cache if available
-	virtual void setPosCache(PainterInfo const &, int, int) const;
 	///
 	void setDimCache(MetricsInfo const &, Dimension const &) const;
 	/// do we cover screen position x/y?
diff --git a/src/insets/InsetIPA.cpp b/src/insets/InsetIPA.cpp
index 1c20866..a574da8 100644
--- a/src/insets/InsetIPA.cpp
+++ b/src/insets/InsetIPA.cpp
@@ -152,7 +152,6 @@ void InsetIPA::draw(PainterInfo & pi, int x, int y) const
 {
 	if (previewState(pi.base.bv)) {
 		preview_->draw(pi, x, y);
-		setPosCache(pi, x, y);
 		return;
 	}
 	InsetText::draw(pi, x, y);
diff --git a/src/insets/InsetPreview.cpp b/src/insets/InsetPreview.cpp
index 37aec63..739322b 100644
--- a/src/insets/InsetPreview.cpp
+++ b/src/insets/InsetPreview.cpp
@@ -139,7 +139,6 @@ void InsetPreview::draw(PainterInfo & pi, int x, int y) const
 	if (previewState(pi.base.bv)) {
 		// one pixel gap in front
 		preview_->draw(pi, x + 1, y);
-		setPosCache(pi, x, y);
 	} else
 		InsetText::draw(pi, x, y);
 }
diff --git a/src/mathed/CommandInset.cpp b/src/mathed/CommandInset.cpp
index 0cf041c..6b94664 100644
--- a/src/mathed/CommandInset.cpp
+++ b/src/mathed/CommandInset.cpp
@@ -58,7 +58,6 @@ Inset * CommandInset::editXY(Cursor & cur, int /*x*/, int /*y*/)
 void CommandInset::draw(PainterInfo & pi, int x, int y) const
 {
 	

Trojan in LyX !!!

[Max Peterson]

Hi,

I have just downloaded LyX-222-Bundle-3.exe and during its installation a
Trojan was found!!!

[image: Inline-Bild 1]

Best regards,
Max.

Re: cumbersome behavior when switching output-engines regarding inputenc

[mn]

On 05.12.16 09:36, Guenter Milde wrote:

>> There might be some incorrect or unexpected behavior when
>> switching output engines in LyX, because Xetex does not
>> support input-encoding settings:
>> To reproduce: Start a document,
> ...
>> Try to compile the document. It will complain that inputenc
>> is not suitable for the chosen engine.
> 
> Not here. It just compiles.
> 
 I just retook the steps I outlined above again and had the same
 error again.
> 
>>> There must be something else in your document. Try with File>New
>>> and see whether this produces the error. If yes, send the
>>> document. If not, tell what else is needed.
> 
>> "Language Package: Always Babel" (a remnant default)
> 
> This is the real reason: Babel-Hebrew is not suited for Unicode
> fonts.

Aha.
Which I thought of as taken care of by LyX, since this was a gui setting.

> Also, it always loads the inputenc package.
> 
> We also need to load inputenc package with one of the Hebrew input 
> encodings. [...] \AtEndOfPackage{% 
> \@ifpackageloaded{inputenc}{}{\RequirePackage[8859-8]{inputenc}}}
> 
> You must use Polyglossia with "non-TeX fonts" and Hebrew (In LyX,
> setting language module to "auto" is recommended.)

Which I will do from now on.
Thanks for the heads up.


>> one line in the preamble loading Minion Pro.
> 
> Actually, loading MinionPro with "use non-TeX fonts" is useless at
> best and could be problematic. The package sets up 8-bit fonts.

I was experimenting with the Xetex-engine I have to use apparently now.
Comparing outputs and fonts and handling opposed to pdflatex.
I was hoping on it to ignore my loading Minion in that way, since I need
to do it that way for pdflatex as setting the Font to Minion via gui is
mysteriously broken (and incomplete).

> Most probabely, the content of the preamble does not matter, anything
> exept an empty user preamble will do (see below).
> 
>> Source View for Format LyX displays "\inputencoding utf8" while set
>> for default-output: XeTeX
> 
> I cannot reproduce this here.
> 
>> To be sure I attached a small file demoing the error as is.
> 
> This reveals one more precondition: Hebrew text in the file. Remove 
> this and it should compile OK. Any text (even ASCII) set to "language
> hebrew" should trigger the error (given the other preconditios), 
> because then Babel-Hebrew loads inputenc.


This pulled-in dependency was completely off-radar for me.
Removing Hebrew text from the file still loads babel but compiles.

> Cannot reproduce with either LyX 2.2 or 2.3(dev).
>
> Now to the mystery:
>
>> Source View for Format LyX displays
>> "\inputencoding utf8"
>> while set for default-output: XeTeX
>
> seems to indicate that you are using LyX 2.1 and a bug in this
> version resulted in a workaround for a bug in your document and a bug
> in inputenc.
> 

But version here is 2.2.2,
as should be clear from the file I attached.

If babel is so problematic for these engines, should LyX not then ignore
these babel settings (which I forced on for pdflatex)?
I do not know how many other (babel)languages pull in inputenc?

> I wonder if you could trigger an: "\inputencoding undefined" error 
> with your document and LyX version when removing the Hebrew text or
> setting the language package to "auto" or "polyglossia".
> 
> In any case, I don't believe we should unhide the inputenc setting 
> with "non-TeX fonts".

Agreed.

That gui setting just sent me on the wrong track to solving this.

If there are not many other scenarios that could trigger roughly the
same or similar behavior it is probably not needed so much as I thought.
(Since I basically shot myself in the foot here.)

Nevertheless I learned another caveat: to really watch out for or decide
very early on top-down what I want to do with a LyX-document.
Some cases allow for experimenting with or switching such settings much
later in the process.

greetings
Mike

Re: LyX might still load hyperref if "use hyperref support" is unchecked

[Jürgen Spitzmüller]

2016-11-23 18:05 GMT+01:00 Scott Kostyshak :

> If there is a hyperlink inset, LyX seems to use hyperref regardless of
> whether "use hyperref support" is checked in document settings. I was
> initially surprised by this (I did not know that the particular document
> used hyperlink insets), although when I realized that hyperlink insets
> were used the behavior of course makes sense.
>
> Currently LyX says "Customize Hyperref Options" if the document class
> provides hyperref. Would it be difficult to extend fa19ec6f to say
> "Customize Hyperref Options" if LyX is going to use hyperref because of
> features within the document, such as an included hyperref inset?
>

Probably not. We would just need to check if hyperref is requested.


> Would we want that?
>
> Trying to think of alternatives to address potential confusion, I only
> came up with having a string in document > settings > PDF Properties
> saying something like "currently this document will use hyperref because
> features in the document (e.g. hyperlinks) need it". But that seems a
> little verbose.
>
> Also, why is it "Use Hyperref Support" and not "Use Hyperref" ? I don't
> see what the word "Support" adds.
>

This is one of these LaTeXisms we want to avoid. I'd prefer something such
as "Enable Hypertext Features and Metadata" and "Customize Hypertext
Features and Metadata". We can mention the hyperref package in the tooltip.
Also note that these features are not only "PDF Properties". Hyperref
supports a wide range of other output formats (via its drivers, e.g. to
HTML and PS).

Jürgen


>
> Scott
>

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 10/11/2016 à 10:19, Jean-Marc Lasgouttes a écrit :

So shall I apply it?


Yes, please.


Done in master at 6dfbab31. Richard, this is candidate for branch too,
since it leads to crashes.


Ping :) Richard, is this OK for branch?

JMarc

Re: cumbersome behavior when switching output-engines regarding inputenc

[Jürgen Spitzmüller]

Am Sonntag, den 04.12.2016, 21:24 +0100 schrieb mn:
> "Language Package: Always Babel" (a remnant default)
> one line in the preamble loading Minion Pro.
> 
> Source View for Format LyX displays
> "\inputencoding utf8"
> while set for default-output: XeTeX
> To be sure I attached a small file demoing the error as is.

The hebrew babel file (hebrew.ldf) internally loads inputenc:

\AtEndOfPackage{%
  \@ifpackageloaded{inputenc}{}{\RequirePackage[8859-8]{inputenc}}}

In other words: Babel Hebrew is not yet ready for non-TeX fonts. You'll
need to use polyglossia.

Jürgen

> 
> 
> greetings
> Mike

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

Re: cumbersome behavior when switching output-engines regarding inputenc

[Guenter Milde]

On 2016-12-04, mn wrote:

> [-- Type: text/plain, Encoding: 7bit --]

> On 04.12.16 20:44, Guenter Milde wrote:
>> On 2016-12-04, mn wrote:
> There might be some incorrect or unexpected behavior when switching
> output engines in LyX, because Xetex does not support input-encoding
> settings:

> To reproduce:
> Start a document,
...
> Try to compile the document.
> It will complain that inputenc is not suitable for the chosen engine.

 Not here. It just compiles.

>>> I just retook the steps I outlined above again and had the same error
>>> again.

>> There must be something else in your document. Try with File>New and see
>> whether this produces the error.  If yes, send the document. If not, tell
>> what else is needed.

> "Language Package: Always Babel" (a remnant default)

This is the real reason: Babel-Hebrew is not suited for Unicode fonts.
Also, it always loads the inputenc package.
   
   We also need to load inputenc package with one of the Hebrew input
   encodings.
   [...]
   \AtEndOfPackage{%
   \@ifpackageloaded{inputenc}{}{\RequirePackage[8859-8]{inputenc}}}

You must use Polyglossia with "non-TeX fonts" and Hebrew (In LyX, setting
language module to "auto" is recommended.)

> one line in the preamble loading Minion Pro.

Actually, loading MinionPro with "use non-TeX fonts" is useless at best and
could be problematic. The package sets up 8-bit fonts.

Most probabely, the content of the preamble does not matter, 
anything exept an empty user preamble will do (see below).

> Source View for Format LyX displays
> "\inputencoding utf8"
> while set for default-output: XeTeX

I cannot reproduce this here.

> To be sure I attached a small file demoing the error as is.

This reveals one more precondition: Hebrew text in the file.
Remove this and it should compile OK. Any text (even ASCII) set to "language
hebrew" should trigger the error (given the other preconditios), because
then Babel-Hebrew loads inputenc.


Cannot reproduce with either LyX 2.2 or 2.3(dev).

Now to the mystery:

> Source View for Format LyX displays
> "\inputencoding utf8"
> while set for default-output: XeTeX

seems to indicate that you are using LyX 2.1 and a bug in this version
resulted in a workaround for a bug in your document and a bug in inputenc.

I wonder if you could trigger an: "\inputencoding undefined" error with your
document and LyX version when removing the Hebrew text or setting the
language package to "auto" or "polyglossia".

In any case, I don't believe we should unhide the inputenc setting with
"non-TeX fonts".

Günter