Start New (Parent) Environment
It seems impossible to get LyX to start a new "Only" environment *via* Edit > Start New (Parent) Environment. (Other environments are affected too.) Please open the attached file and try to insert a new Only environment in the already created frame. Maybe I am overlooking something. Daniel new parent environment.lyx Description: application/lyx
Re: #10481: Hardening LyX against potential misuse
On 04/12/2016 18:37, Guillaume Munch wrote: If there are n graphics, then are there n dialogs when opening the file for the first time? it asks as many times as there are (uncached) graphics needing 'needauth' converters,unless you hit the "Run, and don't ask again for the same doc" button. T.
Re: Outliner problem
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 signature.asc Description: PGP signature
Outliner problem
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. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [LyX/master] Fix display and output of math macros with optional arguments
On Sun, Dec 04, 2016 at 12:22:23AM -0500, Richard Heck wrote: > > Looks good to me. Committed at 9435dd6b. -- Enrico
Re: cumbersome behavior when switching output-engines regarding inputenc
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, go to setup: > - first try something for pdflatex and define under language: input encodig to other (here it was utf8) (then close dialog, reopen dialog and) > >>> Which encoding did you select? > >> Switched from "language default" to "Custom: utf8" > > I suppose the standard "Unicode (utf8), right? > Correct. - switch to fonts, set these to any combination of luatex/Xetex. > >>> Did you mean "tick the 'use non-TeX fonts'" button which activates the >>> "fontspec" package for use of Unicode-encoded fonts? > >> Yes, switch to "Use non-TeX fonts (via XeTeX/LuaTeX)" > >>> With "use non-TeX fonts", both the input encoding and the font >>> encoding are set to "utf-8", overriding any setting under >>> Settings>Language>Encoding. > 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) 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. greetings Mike input-err.lyx Description: application/lyx
Re: LyX and (ancient) Hebrew
Hi, On 3 December 2016 at 23:51, Scott Kostyshak wrote: > > > > If I may offer some suggestions... I am not a programmer who can > implement > > this, but I use Hebrew in LyX quite often, including ancient Hebrew with > > everything on it. Xetex is the only one, in my experience, that is really > > working. > > Good to know. I wonder if we should set our Hebrew manuals to XeTeX by > default. XeTeX is by far the best option today to typeset Hebrew and LyX should default to it. Culmus-latex and ivritex (the old ways to get Hebrew working) are no longer actively maintained as they are inferior in almost any sense. A while a go I wrote a simple tutorial to get an Hebrew document working using LyX and XeTeX. https://www.guyrutenberg.com/2015/03/21/creating-a-hebrew-document-in-lyx-2-1-with-xetex/ Regards, Guy
module basic
Hey guys, I just compiled master and fired it up to poke around. It launches ok but when I try and create a new document I'm met with a dialogue saying: The module basic has been requested by this document but has not been found in the list of available modules. If you recently installed it, you probably need to reconfigure LyX. Any thoughts? My platform is: Darwin Kernel Version 16.1.0 (MacOS Sierra) My configure command is: ./configure --with-qt-dir=/opt/local/libexec/qt5 --enable-qt5 --prefix=/Users/ian/Applications/LyX-master.app Thanks, Ian
Re: cumbersome behavior when switching output-engines regarding inputenc
On 2016-12-04, mn wrote:
> On 04.12.16 16:09, Guenter Milde wrote:
>> On 2016-12-03, 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, go to setup:
>>> - first try something for pdflatex and
>>> define under language: input encodig to other (here it was utf8)
>>> (then close dialog, reopen dialog and)
>> Which encoding did you select?
> Switched from "language default" to "Custom: utf8"
I suppose the standard "Unicode (utf8), right?
>>> - switch to fonts, set these to any combination of luatex/Xetex.
>> Did you mean "tick the 'use non-TeX fonts'" button which activates the
>> "fontspec" package for use of Unicode-encoded fonts?
> Yes, switch to "Use non-TeX fonts (via XeTeX/LuaTeX)"
>> With "use non-TeX fonts", both the input encoding and the font
>> encoding are set to "utf-8", overriding any setting under
>> Settings>Language>Encoding.
>>> 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.
> ###
> ! Package inputenc Error: inputenc is not designed for xetex or luatex.
> (inputenc)only UTF-8 supported.
> See the inputenc package documentation for explanation.
> Type H for immediate help.
> ...
> l.158 \endinput
This should not happen with "use non-TeX fonts".
> For xelatex or lualatex save the document in UTF-8 encoding
> and do not use inputenc, or use the [utf8] option.
LyX does not use inputenc if "non-TeX fonts" are used. The setting under
language>encoding is ignored.
> ###
> But I found that my usual way of invoking MinionPro for default roman
> for pdflatex is apparently the culprit:
> The preamble-code
> \usepackage[textosf,mathlf]{MinionPro}
> seems to trigger the behavior outlined above.
> Although I fail to see why.
> None of the related .sty-files pull in inputenc?
The full log will tell you, which file loaded inputenc.
All loaded files are logged and nesting is indicated by ().
>>> But then going back to doc-settings and just trying to unset the
>>> other(utf8)-option back to default is inaccessible (greyed out).
>>> To do anything about that you have to first also unset your
>>> font-settings back to choices for pdflatex.
>> Did changing the input encoding setting under Language>Encoding help
>> to make
>> your document compile again? Which setting was required? Did it work with
>> "non-TeX fonts" later?
> Yes. For both tests when it failed and also when I noticed this behavior
> in another document: unsetting first "Use non-TeX-fonts" and then
> changing input encoding back to default, then rechecking "Use
> non-TeX-Fonts" produced a PDF that compiled with XeTeX and looked as
> expected.
Strange.
> Together with the apparent trigger mentioned above I currently do not
> understand why un/checking inputenc:utf8 in LyX's gui has any influence
> on this situation if it is ignored by LyX for XeTeX in he way you decribed.
It would be interesting to see the diff of the exported files with
and without Language>Encoding set to utf8.
You may spot a difference either with View>Source (complete document or
preamble) or File>Export>latex (XeTeX).
Günter
Re: [LyX/master] Cosmetic changes to the needauth dialogs
On Sun, Dec 04, 2016 at 06:38:42PM +0100, Guillaume Munch wrote:
> commit 588d939722f4a516e8e4a932086e574bc3b13065
> Author: Guillaume Munch
> Date: Sun Dec 4 18:28:03 2016 +0100
>
> Cosmetic changes to the needauth dialogs
>
> * Use rich text for this complicated message
>
> * More concise
>
> * Fix line breaking issues
>
> * Remove "Do not show again" checkbox
>
[...]
>
> +// FIXME: This dialog has issues with line breaking and size, in particular
> with
> +// html. But it could easily be reimplemented as a QMessageBox using
> +// QMessageBox::setCheckBox() available starting from Qt 5.2
> class GuiToggleWarningDialog : public QDialog, public Ui::ToggleWarningUi
> {
> public:
If this is true, it would be better to actually reimplement it and
conditionally compile for Qt >= 5.2, otherwise this risks staying so
for ever (or almost so).
--
Enrico
Re: #10481: Hardening LyX against potential misuse
Am Sonntag, 4. Dezember 2016 um 18:51:15, schrieb Guillaume Munch > Le 04/12/2016 à 18:06, Tommaso Cucinotta a écrit : > > On 28/11/2016 00:42, Tommaso Cucinotta wrote: > >> On 27/11/2016 13:52, Guillaume Munch wrote: > >>> * Converters>Security is located below the converter configuration, > >>> which leads to think that they are converter properties instead of > >>> global settings. What about placing it above the converter list? > >> > >> Same problem with the Converter Cache option already, isn't it? > >> > >> Let me propose the attached fix for both at once. > > > > just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm > > it shows up as intended ... > > > > How is it supposed to show up? Can you send a screenshot? Here only the > font of "Converters Definition" changed, and I still find it unclear. Dialog looks good. There seems to be missing in "The requested operation requires the use of a converter from %2$s to %3$s:" "%1$sThis external program can execute " "arbitrary commands on your system, including dangerous ones, if instructed " "to do so by a maliciously crafted .lyx document." Kornel signature.asc Description: This is a digitally signed message part.
Re: Crash in stable
On Sun, Dec 04, 2016 at 07:01:51PM +0100, Guillaume Munch wrote: > Le 04/12/2016 à 18:48, Enrico Forestieri a écrit : > > I am confused now. You make a convoluted patch justifying it by saying > > that it was done in view of a proper fix. The simpler one-liner has the > > same effect and actually would not be possible if the proper fix was in > > place. Given that it is not backported to branch, the simpler fix is > > preferable. But I am not going to argue further, as I don't seem to be > > able to follow your logic. > > > > And I am not going to argue further, because I gave reasons for why it > is preferable to have the one closest to master out of the two. Amen -- Enrico
Re: Crash in stable
Le 04/12/2016 à 18:48, Enrico Forestieri a écrit : I am confused now. You make a convoluted patch justifying it by saying that it was done in view of a proper fix. The simpler one-liner has the same effect and actually would not be possible if the proper fix was in place. Given that it is not backported to branch, the simpler fix is preferable. But I am not going to argue further, as I don't seem to be able to follow your logic. And I am not going to argue further, because I gave reasons for why it is preferable to have the one closest to master out of the two.
Re: #10481: Hardening LyX against potential misuse
On Sun, Dec 04, 2016 at 06:06:57PM +0100, Tommaso Cucinotta wrote: > On 28/11/2016 00:42, Tommaso Cucinotta wrote: > > On 27/11/2016 13:52, Guillaume Munch wrote: > > > * Converters>Security is located below the converter configuration, > > > which leads to think that they are converter properties instead of > > > global settings. What about placing it above the converter list? > > > > Same problem with the Converter Cache option already, isn't it? > > > > Let me propose the attached fix for both at once. > > just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm it > shows up as intended ... I did not follow this conversation closely, but here are my comments: Keep in mind that most LyX users do not know what a file cache is. Can you describe exactly what's being cached in the tooltip? Maybe you could use the word "remembered" instead of "cached" in the tooltip because it is a more user-friendly word? A tooltip for maximum age would also be useful. e.g. "after this amount of days, ..." I wonder if the cache should expire after e.g. 60 days, or after 60 days since the last use of the file. For example, I (think I) would want it to be 60 days since the last use of the file, but I don't know if that's what would be best for the general user. I think you want some kind of validator for the maximum age. I put in a negative number and after saving it turned it into 49651.3. I'm guessing you want to restrict to only non-negative integers? Look at other places we use validators for similar text boxes. Also what would happen if I put in 0? Does that effectively mean the converter file cache is disabled? Or is it a special value that means "never expire"? Thanks for your work on this! Scott signature.asc Description: PGP signature
Re: #10481: Hardening LyX against potential misuse
Le 04/12/2016 à 18:06, Tommaso Cucinotta a écrit : On 28/11/2016 00:42, Tommaso Cucinotta wrote: On 27/11/2016 13:52, Guillaume Munch wrote: * Converters>Security is located below the converter configuration, which leads to think that they are converter properties instead of global settings. What about placing it above the converter list? Same problem with the Converter Cache option already, isn't it? Let me propose the attached fix for both at once. just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm it shows up as intended ... How is it supposed to show up? Can you send a screenshot? Here only the font of "Converters Definition" changed, and I still find it unclear.
Re: Crash in stable
On Sun, Dec 04, 2016 at 06:21:53PM +0100, Guillaume Munch wrote: > Le 04/12/2016 à 17:04, Enrico Forestieri a écrit : > > > > Weak arguments, given that you say the patch was written with the > > proper fix in mind (which is not in stable). > > It is probably clear to Enrico (I hope) but maybe less to people who did > not follow the discussions and the mentioned commits too closely, that > "proper fix" refers to the pointer becoming invalid. This fix is > only meant to avoid bugs of the same kind in the future. Enrico's > "one-liner" does nothing about it. It is not in stable because nobody > is asking to backport it, because it would be useless there. Then this > fix for a problem B is supposed to be somehow related to the qualities > of a solution to problem A in stable, and if he is serious then I have > to admit that then his argument escapes me. I am confused now. You make a convoluted patch justifying it by saying that it was done in view of a proper fix. The simpler one-liner has the same effect and actually would not be possible if the proper fix was in place. Given that it is not backported to branch, the simpler fix is preferable. But I am not going to argue further, as I don't seem to be able to follow your logic. > > It would be better if you post your patches to stable for approval > > and comments before committing them. > > > > In fact there was a private exchange with Richard on Friday when I saw > the report, apologies to the list for not being included in the > recipients but I was away without access to my usual git&gmane > configuration, and I wanted to spare people time wasted in a duplicate > fix. But from the discussion it was clear to me that Richard intended to > backport 79a947c9 in case it worked. Hmmm... -- Enrico
Re: #10481: Hardening LyX against potential misuse
Le 28/11/2016 à 00:42, Tommaso Cucinotta a écrit : eh eh, what about remembering 'needauth' (as well as cursor pos) only for those files in the recent files list :-), and collapse the 3 lists into a single one, and a single session section ? Two problems I see with this idea is that migrating the user session is going to require some work which can be avoided, and also that the three lists may have different age/length requirements, for instance the recent files is limited to what you see in the menu. * Please see the attached patch for a few suggestions looks great, HTML provides a much better graphics :-), feel free to push ! Done * Converters>Security is located below the converter configuration, which leads to think that they are converter properties instead of global settings. What about placing it above the converter list? Same problem with the Converter Cache option already, isn't it? Let me propose the attached fix for both at once. You made me realise that the converter cache option is indeed global. So it's good to fix both, thanks. browse to the Sweave converters, and you'll see the needauth option in the extraflags, guess we can edit as well from the dialog, can't we? Ok, I did not realise. 1. graphics on-screen conversion & display, used with my (local) gnuplot patch, so I insert a .gnuplot image file, and I see its produced output pic on screen, ..., after a few warnings about running needauth converters :-)... If there are n graphics, then are there n dialogs when opening the file for the first time? what else, what are further calls to converters? Thanks for the explanations, I don't see other calls to converters. Guillaume
Re: LyX and (ancient) Hebrew
On 04.12.16 17:58, Scott Kostyshak wrote: > On Sun, Dec 04, 2016 at 05:38:14PM +0100, mn wrote: > >> Something like an MWE is attached. >> Here, it triggers slowness on loading the file into a fresh LyX session. > I cannot reproduce with just your example. But if I select all and then > paste 10 times, then I can get some slowness with cursor movement, > selection and scrolling. Pasting this paragraph 10 times is enough to make LyX really glacial. > Note that if you have continuous spellcheck enabled and source preview, > these two things can slow down cursor movement. Source view is usually closed. When I tested it with continuous spell-check enabled it is indeed much much slower than without. Then again the spell-checkers seem to be quite clueless about what's written there. Setting spellchecker to either "aspell" or "native" seems to improve the situation somewhat but it's hard to quantify which of both options is better. Regarding speed, both are clearly superior to hunspell, which slows LyX to an absolute crawl. But aspell and native seem to just ignore all the hebrew text? Nothing is marked with both of them enabled, whereas hunspell seems to mark a lot of the text as somehow incorrect.
Re: Crash in stable
Le 04/12/2016 à 17:04, Enrico Forestieri a écrit : Weak arguments, given that you say the patch was written with the proper fix in mind (which is not in stable). It is probably clear to Enrico (I hope) but maybe less to people who did not follow the discussions and the mentioned commits too closely, that "proper fix" refers to the pointer becoming invalid. This fix is only meant to avoid bugs of the same kind in the future. Enrico's "one-liner" does nothing about it. It is not in stable because nobody is asking to backport it, because it would be useless there. Then this fix for a problem B is supposed to be somehow related to the qualities of a solution to problem A in stable, and if he is serious then I have to admit that then his argument escapes me. It would be better if you post your patches to stable for approval > and comments before committing them. In fact there was a private exchange with Richard on Friday when I saw the report, apologies to the list for not being included in the recipients but I was away without access to my usual git&gmane configuration, and I wanted to spare people time wasted in a duplicate fix. But from the discussion it was clear to me that Richard intended to backport 79a947c9 in case it worked.
Re: #10481: Hardening LyX against potential misuse
On 28/11/2016 00:42, Tommaso Cucinotta wrote: On 27/11/2016 13:52, Guillaume Munch wrote: * Converters>Security is located below the converter configuration, which leads to think that they are converter properties instead of global settings. What about placing it above the converter list? Same problem with the Converter Cache option already, isn't it? Let me propose the attached fix for both at once. just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm it shows up as intended ... Thx, T.
Re: LyX and (ancient) Hebrew
On Sun, Dec 04, 2016 at 05:38:14PM +0100, mn wrote: > Something like an MWE is attached. > Here, it triggers slowness on loading the file into a fresh LyX session. Thanks for your persistence and this example! I cannot reproduce with just your example. But if I select all and then paste 10 times, then I can get some slowness with cursor movement, selection and scrolling. Note that if you have continuous spellcheck enabled and source preview, these two things can slow down cursor movement. Scott signature.asc Description: PGP signature
Re: LyX and (ancient) Hebrew
On 04.12.16 02:50, Scott Kostyshak wrote: > On Sat, Dec 03, 2016 at 10:26:17PM +0100, mn wrote: >> On 03.12.16 21:43, Scott Kostyshak wrote: >> BTW: Until now I only had simple and short strings entered myself into an otherwise empty document. Copying this rather complex but still short example into LyX makes it quite slow to handle and beachballing a lot. There seems to be a problem handling this (script or unicode or whatnot). >>> >>> Good to know. Can you give some enumerated simple steps to reproduce? >>> And where exactly do you see the slow part? (when copying, when >>> pasting?) I do not see slowness, but I think it's because I >>> misunderstood. Please do this in a separate email to lyx-devel so we can >>> separate the conversations. >>> >> >> 1. new document >> 2. output font set to Xetex/SBL-Hebrew >> 3. main document language set to English >> 4. paste Hebrew text >> beachball >> 5. set pasted text to language Hebrew >> beachball >> 6. paste English text >> beachball >> 7. set English text to language English >> beachball >> 7. scrolling >> beachball then quite slow scrolling >> 8. resize window, >> short beachball >> 9. pasting the same English block again >> beachball >> 10 pasting English block again >> beachball or delay (delay is ~ for 2-3 seconds) >> >> It seems to occur right after the clipboard buffer gets pasted into the >> editor buffer / LyX's system. >> Source of the text was OSHB sword module copied from Alkitab. >> (i.e. I do not know if that has problems on its own) >> But it seems to be an unproblematic block of characters in other >> Mac-applications (speed-wise). > > I can't reproduce on Ubuntu. Stephan, can you reproduce on Mac? > One interesting tidbit: After copying and pasting Gen 1 in vocalized Hebrew three times into the document and alternating this with three paragraphs in English: LyX starts to beachball for >5 seconds (up to a minute) for every action taken. That is 5 seconds for one cursor movement one character position to the right for example. Opening LyX's preferences takes around 20 seconds while beachballing. When a new document tab is then opened and no Hebrew is there, then the speed is back to normal. For every action taken. Insert as mush latin characters as you like. Until you start with Hebrew again. Something like an MWE is attached. Here, it triggers slowness on loading the file into a fresh LyX session. For proper PDF-output you will need the SBL-Hebrew font as specified in the preamble from here: https://www.sbl-site.org/educational/BiblicalFonts_SBLHebrew.aspx greetings mn GenXeTeX.lyx Description: application/lyx
Re: Crash in stable
On Sun, Dec 04, 2016 at 01:01:13PM +0100, Guillaume Munch wrote: > Le 04/12/2016 à 12:25, Enrico Forestieri a écrit : > > On Sun, Dec 04, 2016 at 11:57:29AM +0100, Guillaume Munch wrote: > > > > > Le 04/12/2016 à 00:57, Enrico Forestieri a écrit : > > > > On Sat, Dec 03, 2016 at 11:59:33PM +0100, Guillaume Munch wrote: > > > > > > > > > > This is the same as > > > > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196794.html. I > > > > > have now backported the fix. > > > > > > > > Hmmm... a quite convoluted patch. There was a one-liner fixing this. > > > > > > > > > > But then you are repeating the discussion above. What point are you > > > trying to make? > > > > Given two equivalent patches, the simpler is preferable. > > > > The patch which is preferable is the one that deviates the less from > master, because: > * it is already tested, > * it causes fewer merge conflicts with future backports. > > In this case indeed, the backported code is still in master because it > was written with the proper fix at e0e765f6a98 in mind, as I explained > in the previous discussion. Weak arguments, given that you say the patch was written with the proper fix in mind (which is not in stable). It would be better if you post your patches to stable for approval and comments before committing them. -- Enrico
Re: cumbersome behavior when switching output-engines regarding inputenc
On 04.12.16 16:09, Guenter Milde wrote:
> On 2016-12-03, 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, go to setup:
>
>> - first try something for pdflatex and
>> define under language: input encodig to other (here it was utf8)
>> (then close dialog, reopen dialog and)
>
> Which encoding did you select?
>
Switched from "language default" to "Custom: utf8"
>> - switch to fonts, set these to any combination of luatex/Xetex.
>
> Did you mean "tick the 'use non-TeX fonts'" button which activates the
> "fontspec" package for use of Unicode-encoded fonts?
>
Yes, switch to "Use non-TeX fonts (via XeTeX/LuaTeX)"
> With "use non-TeX fonts", both the input encoding and the font
encoding are
> set to "utf-8", overriding any setting under Settings>Language>Encoding.
>
>> 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.
###
! Package inputenc Error: inputenc is not designed for xetex or luatex.
(inputenc)only UTF-8 supported.
See the inputenc package documentation for explanation.
Type H for immediate help.
...
l.158 \endinput
For xelatex or lualatex save the document in UTF-8 encoding
and do not use inputenc, or use the [utf8] option.
###
But I found that my usual way of invoking MinionPro for default roman
for pdflatex is apparently the culprit:
The preamble-code
\usepackage[textosf,mathlf]{MinionPro}
seems to trigger the behavior outlined above.
Although I fail to see why.
None of the related .sty-files pull in inputenc?
>> But then going back to doc-settings and just trying to unset the
>> other(utf8)-option back to default is inaccessible (greyed out).
>> To do anything about that you have to first also unset your
>> font-settings back to choices for pdflatex.
>
> Did changing the input encoding setting under Language>Encoding help
to make
> your document compile again? Which setting was required? Did it work with
> "non-TeX fonts" later?
>
Yes. For both tests when it failed and also when I noticed this behavior
in another document: unsetting first "Use non-TeX-fonts" and then
changing input encoding back to default, then rechecking "Use
non-TeX-Fonts" produced a PDF that compiled with XeTeX and looked as
expected.
Together with the apparent trigger mentioned above I currently do not
understand why un/checking inputenc:utf8 in LyX's gui has any influence
on this situation if it is ignored by LyX for XeTeX in he way you decribed.
>> This is wrong imho.
>
>> I think LyX should keep these settings for the usage case "switching
>> engines" but gracefully ignore inputenc settings for Xetex.
>
>> This was presumably intended to keep users from messing with inputenc
>> once Xetex was the chosen output engine for a document, but it is
>> confusing when you only find out later that you might have to use Xetex
>> instead of pdflatex.
>
> There is an important distinction between "use XeTeX/LuaTeX" and "use
> Unicode fonts" that even major LaTeX packages get wrong.
>
> Also, the custom counsel "use XeTeX" or "use LuaTeX" given to users with
> font problems or script problems is misleading. Switching the engine does
> not help without switching the fonts, too. Usually, this implies use
of the
> "fontspec" package, in LyX by ticking the "use non-TeX fonts" button.
>
> You can use XeTeX or LuaTeX and 8-bit TeX fonts (and there are rare but
> valid use cases).
>
> However, because even the creators of the basic "inputenc" package did
> get this wrong and added a test, XeTeX can no longer be used with
> inputenc when the input encoding is set to something other than "ascii".
> Therefore, LyX overrides the user-choice in Settings>Language>Encoding
> with XeTeX and 8-bit TeX-fonts. This can lead to errors when the document
> contains characters that LyX cannot convert to ascii.
Thanks for the explanation.
greetings
Mike
Re: cumbersome behavior when switching output-engines regarding inputenc
On 2016-12-03, 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, go to setup: > - first try something for pdflatex and > define under language: input encodig to other (here it was utf8) > (then close dialog, reopen dialog and) Which encoding did you select? > - switch to fonts, set these to any combination of luatex/Xetex. Did you mean "tick the 'use non-TeX fonts'" button which activates the "fontspec" package for use of Unicode-encoded fonts? With "use non-TeX fonts", both the input encoding and the font encoding are set to "utf-8", overriding any setting under Settings>Language>Encoding. > Try to compile the document. > It will complain that inputenc is not suitable for the chosen engine. Not here. It just compiles. > But then going back to doc-settings and just trying to unset the > other(utf8)-option back to default is inaccessible (greyed out). > To do anything about that you have to first also unset your > font-settings back to choices for pdflatex. Did changing the input encoding setting under Language>Encoding help to make your document compile again? Which setting was required? Did it work with "non-TeX fonts" later? > This is wrong imho. > I think LyX should keep these settings for the usage case "switching > engines" but gracefully ignore inputenc settings for Xetex. > This was presumably intended to keep users from messing with inputenc > once Xetex was the chosen output engine for a document, but it is > confusing when you only find out later that you might have to use Xetex > instead of pdflatex. There is an important distinction between "use XeTeX/LuaTeX" and "use Unicode fonts" that even major LaTeX packages get wrong. Also, the custom counsel "use XeTeX" or "use LuaTeX" given to users with font problems or script problems is misleading. Switching the engine does not help without switching the fonts, too. Usually, this implies use of the "fontspec" package, in LyX by ticking the "use non-TeX fonts" button. You can use XeTeX or LuaTeX and 8-bit TeX fonts (and there are rare but valid use cases). However, because even the creators of the basic "inputenc" package did get this wrong and added a test, XeTeX can no longer be used with inputenc when the input encoding is set to something other than "ascii". Therefore, LyX overrides the user-choice in Settings>Language>Encoding with XeTeX and 8-bit TeX-fonts. This can lead to errors when the document contains characters that LyX cannot convert to ascii. Günter
Re: Crash in stable
Le 04/12/2016 à 12:25, Enrico Forestieri a écrit : On Sun, Dec 04, 2016 at 11:57:29AM +0100, Guillaume Munch wrote: Le 04/12/2016 à 00:57, Enrico Forestieri a écrit : On Sat, Dec 03, 2016 at 11:59:33PM +0100, Guillaume Munch wrote: This is the same as https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196794.html. I have now backported the fix. Hmmm... a quite convoluted patch. There was a one-liner fixing this. But then you are repeating the discussion above. What point are you trying to make? Given two equivalent patches, the simpler is preferable. The patch which is preferable is the one that deviates the less from master, because: * it is already tested, * it causes fewer merge conflicts with future backports. In this case indeed, the backported code is still in master because it was written with the proper fix at e0e765f6a98 in mind, as I explained in the previous discussion.
Re: Crash in stable
On Sun, Dec 04, 2016 at 11:57:29AM +0100, Guillaume Munch wrote: > Le 04/12/2016 à 00:57, Enrico Forestieri a écrit : > > On Sat, Dec 03, 2016 at 11:59:33PM +0100, Guillaume Munch wrote: > > > > > > This is the same as > > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196794.html. I > > > have now backported the fix. > > > > Hmmm... a quite convoluted patch. There was a one-liner fixing this. > > > > But then you are repeating the discussion above. What point are you > trying to make? Given two equivalent patches, the simpler is preferable. -- Enrico
Re: Crash in stable
Le 04/12/2016 à 00:57, Enrico Forestieri a écrit : On Sat, Dec 03, 2016 at 11:59:33PM +0100, Guillaume Munch wrote: This is the same as https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196794.html. I have now backported the fix. Hmmm... a quite convoluted patch. There was a one-liner fixing this. But then you are repeating the discussion above. What point are you trying to make?
