Guenter Milde wrote:

> On 2015-11-12, Georg Baum wrote:
> 
>> (and the most important reason for me personally is that you can set an
>> explicit default format per document: an automatic choice of non-TeX
>> would eliminate uncompilable documents if such a default format is
>> set).
> 
> This is also already possible, however it is non-intuitive.
> You have to do this at two places: besides Settings>Output you also have
> to make sure there is a matching Settings>Fonts>useNonTeXFonts.

Well, this is exactly what I meant: By changing the default output format 
(and nothing else) you can currently make a document non-compilable for the 
default output format. A non-working default format is (IMHO) more important 
than the existence of any other menu entry that produces an output format 
that does not work.

>> What I want is a solution for the "double automatic" problem: What is the
>> default output format if it is set to automatic in the document, and
>> non-TeX fonts are set to automatic as well?
> 
> Generic rule: every automatic choice should use the "current best
> practice". (CBP) We do this for many cases, e.g. font encoding, language
> package, inputenc (where IMO the current choice is "past best practice"),

What is wrong with our inputenc usage (assuming that xetex or luatex cannot 
be used)? Is the utf8 inputenc mess finally fixed?

> The problem is to agree on the CBP, as there are many different use cases
> and work-flows. But I don't see the "double automatic" as more of a
> problem than the other automatic choices. It is just that the
> "useNonTeXFonts == auto" setting would free us to select a sensible
> default output format.

The problem is also to find out what the CBP is for a particular document. 
Simply using latex (independent of the document contents) is not CPB for all 
documents IMO.

>> None of the discussed solutions was convincing so far for me:
> 
>> 1) Use latex as engine for the default output format and automatic fonts
>> as in my initial patch. This is an arbitrary choice and intransparent for
>> the user.
> 
> This is the backwards compatible choice: no change in LyX-behaviour if you
> change the standard template to have "useNonTeXFonts = auto".

I don't think that 'backwards compatible' is the best term to use here. I 
know what you mean (same behaviour of LyX when switching from TeX fonts to 
auto), but 'backwards compatible' is better used for files IMHO. Otherwise 
it implies that setting "use TeX fonts" always on is the 'old' setting, but 
this is not true. It is the setting to use if you have ERT that requires to 
use TeX fonts.

> No surprises to the user are a strong argument, therefore, this is my
> favourite.

It is no surprise if you compare automatic with TeX fonts. If you compare it 
with non-TeX fonts, then the behaviour may change, and there is no other 
explanation for it than "we had to make a choice, so we assumed using TeX 
fonts is better". I would want a choice that does not depend on assumptions 
on our side, but that depends on the document.

> However, there is now a choice that we have to communicate:
> 
> Possible actions for using fontspec (i.e. Unicode fonts)
> would be:
> 
> a) export/view with XeTeX or LuaTeX via the "other formats" button/menu
> 
> b) set XeTeX/LuaTeX in Document>Settings>Output Default output format
> 
> c) set Document>Settings>Fonts>useNonTeXFonts
> 
> with the differences
> 
> a) is a one-of choice at export time (by the author or a reader).
> 
> b) is the authors choice for a preference for this document not preventing
>    export with TeX fonts.
>    
> c) is the authors choice, indicating that this document must be "latexed"
>    with fontspec. This prevents compilation with 8-bit TeX.
> 
> Currently, the only choice is c).

I don't understand. a) and b) are currently possible as well, they would 
only be made easier to use.

>> 2) Have only one Default Output Format under
>> Tools>Preferences>File>Handling instead of two. Then the default output
>> format of a document with automatic TeX/non-TeX fonts would be the one
>> defined in preferences. Depending on the document contents the default
>> output format may not work at all.
> 
>> 3) Like 2), but with a hard coded substitution list for the cases that
>> the selected format does not work. This would be heavily intransparent
>> for the user: You would need to know a lot of the internals to understand
>> why the default output format would use pdflatex, although you set
>> non-TeX fonts to automatic, and chose XeTeX as default output format in
>> the preferences.
> 
>> 4) Like 3), but with a user configurable substitution list. This would
>> not be intransparent anymore, but still quite difficult to understand.
> 
> We could make the current choices a "two line substitution list":
> 
> The key and tooltip in Tools>Preferences>File>Handling should state that
> the first setting is tried first and the second one is a substitute (for
> the case the first fails).

I don't think that many users would understand that. As a user I would ask: 
What does "in case it fails" mean? Did I do something wrong if it fails? Is 
LyX just crappy software trying to work around internal bugs?

> Again, with the current defaults, this would not change the default
> behaviour, so most users will not realise this change at all.
> (Remember, this setting is hard to find, as it is "hidden" under
>  File Handling > File Formats while the document-specific default is
>  under Document>Settings>Output.)

Now you are cheating. Where to put this preference is completely independent 
of an automatic setting. Either there is a good reason for having it in the 
output pane, then we should keep it there, or there is no such reason, then 
we should move it as you suggested earlier. I am currently not aware of any 
reason to have it in the output pane BTW.

> But it would open the possibility for a user to set Xe/LuaTeX as the
> preferred format (used also for documents that are compilable with both
> flavours). Or to try HTML first and PDF only if this fails...

What would be the use case for an automatic HTML->PDF failover? Usually you 
need a specific output format (e.g. PDF), the only choice is how you produce 
it.

>> 5) Remove the default output format completely and recommend to use
>> automatic non-TeX fonts. This would be quite radical, and I am not sure
>> it would cover all use cases. One would need to think more about it.
> 
> I don't like this one, as it is a great advantage not to have to decide
> about the output format with every export/view.

I don't like it either, I just added it for completeness.

>>> The automatic font package selection (fontenc vs. fontspec) would be
>>> similar to the automatic language package selection (babel vs.
>>> polyglossia).
> 
>> Almost: No other automatic setting is undefined if the language package
>> is set to automatic.
> 
> However, currently, the only way to force "polyglossia" (in case you have
> polyglossia-specific ERT, say) is setting "useNonTeXFonts: True" and
> "language-package: auto". Not intuitive.

Yes, this is not intuitive. But this calls for a "polyglossia" language 
setting in addition to "auto" and "babel" IMHO.

>>> However, the most problematic part (for me) is, that the obscure
>>> combinations XeTeX/LuaTeX & TeX fonts are simpler to reach than the much
>>> more use full LuaTeX & OpenType fonts.
> 
>> Yes, this is not nice, but the drawbacks of the solutions for the "double
>> automatic" above play in a similar category IMHO.
> 
> I don't think so. As long as the default behaviour stays backwards
> compatible, the benefits outweigh the problems.

It looks like we can stop the discussion here, since we are obviously moving 
in circles: You keep repeating how important the automatic switch is, and I 
keep repeating what I wrote on Nov. 6th: "However, we do not yet have a 
transparent and easy to understand solution for the "double automatic" 
problem. Once we have such a solution I am also fine with having the 
automatic switch."
I have uploaded my half finished work at 
http://www.lyx.org/trac/ticket/9744, so anybody who is interested can 
continue to work on it (e.g. the GUI part of the patch is crap).


Georg

Reply via email to