On 2015-11-12, Georg Baum wrote: > Guenter Milde wrote: >> The current GUI design is inconsistent if you want to export to the most >> common document types:
>> 1. DVI TeX fonts for the TeX nostalgic >> 2. PS TeX fonts for fast preview/printing and PS-tricks >> 3. PDF (pdflatex) TeX fonts for traditional PDF >> 4. PDF (XeTeX) OpenType fonts for the traditional Unicode user >> 5. PDF (LuaTeX) OpenType fonts for the adventurous Unicode user >> 6. LyXHTML OpenType fonts for online use >> You can select between 1, 2, 3, and 6 from the "see other formats" >> toolbar buttons or menu entry, without need to change the source document. > Not in practice. 6. does not work for many documents (because of ERT) and > requires many more changes than just toggling a single button. But this is not a principal restriction but due to specific document content. It is already possible to create documents that can be exported without change to 1, 2, 3, and 6 without need to change the source document. (This would become more easy, if we introduce EGT (evil green text == raw HTML;)) OTOH, it is currently not possible to create a document that can be exported to 3. and 4. without change to the source. ... > (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. > 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"), ... 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. > 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". No surprises to the user are a strong argument, therefore, this is my favourite. 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). > 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). 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.) 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... > 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. Also, this would mean you have to think about formats that work/fail with every view. Just imagine you get a LyX document from someone else and want to compile it. >> 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. >> 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. Günter
