Following a request by Günter, we consider the document fonts (only rm
for now) when selecting an appropriate font encoding.
See #9741
The new default font encoding setting "auto" does
* consider the font encoding needed by the language(s), which can now
have fallback alternatives
* Consider which font encoding is provided by the document font
Thus, cm now will result in OT1 fontenc, if the language can deal with
that.
The font_enc pref is ditched: it is no longer needed.
The automatism is still very basic and is subject to extension.
File format and prefs format change.
Biblatex can be used with Japanese, but then, biber (not pbibtex) should
be used as processor.
I this context, bring the jbibtex UI in line with bibtex, allowing for
a selection of alternatives.
This variable was introduced to guard against any bad consequence of the then-new right-to-left
languages support. Let's be bold and get rid of it altogether!
Now right to left support is always enabled.
Fedora ships these chmod 644 and has never seen a problem. The advantage
to doing this is that it better controls what version of python we are
using to launch the script, and it will reveal if we're somehow somewhere
not controlling that properly.
(unless it's already there, in which case it should move to the end of the next paragraph).
Change the preference setting name (mac_like_word_movement to mac_like_cursor_movement)
to better reflect its function.
Patch and description from Bennett Helm
Previously, the format used for included pdf files was the same as for
document export via ps2pdf. This caused unwanted conversion routes, e.g.
export via odt->pdf instead of dvi->ps->pdf.
I renamed the format for included graphics and not for exported documents,
since otherwise the command line syntax for export would change. This would
require more adaptions for the users, since with the chosen solution the
custom converters are almost always changed correctly in prefs2prefs(),
so that only custom external templates need manual adjustement.
- This preference was used for specifying the papersize to xdvi, dvipdfm,
dvips. However, I can't seem to see any effect on the result.
- The papersize should instead be defined in the document settings.
- The global papersize default was misused to also change the tex
output by specifying the papersize as if it was specified in the
document settings. This caused the same lyx document to be outputted
differently on different pcs.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40028 a592a061-630c-0410-9148-cb99ea01b6c8
(e.g., compressed dia, odg, sxd, ...). These need to be marked via the "zipped=native" flag in the RC file.
The old 'dia' configuration is automatically updated (it used to be hardcoded in the code, now it is handled
via the flag).
See also http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg170974.html
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39705 a592a061-630c-0410-9148-cb99ea01b6c8
Additionnal extensions are separated by commas (,) in lyxrc
preference files, while spaces are ignored, e.g. "jpg, jpeg".
Preference lyxrc file format incremented to 2.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39670 a592a061-630c-0410-9148-cb99ea01b6c8
Use a list of [int, list of functions] pair, representing
- int: the format number, and
- list of functions: what needs to be done to the file to
update it to the given format number.
This matches what is done in lyx2lyx and helps keeping track of
format numbers and their corresponding conversion routines.
Also, add another sanity check.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39668 a592a061-630c-0410-9148-cb99ea01b6c8
listed in file->export menu). Do not remove customized
document formats from the export menu.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38975 a592a061-630c-0410-9148-cb99ea01b6c8
prefs2prefs_lfuns.py and prefs2prefs_prefs.py. I've organized it this way because, in many ways, these are
the same task. It's very line-by-line, unlike lyx2lyx and layout2layout, where things can be more "global".
So we read the file, line by line, and give a bunch of converter functions a chance to see if they want to
modify that line.
The converter functions are all in the subsidiary files. (Only the lfun one has anything in it now.) They
take a line as argument and return a list: (Bool, NewLine), where the Bool says if we've modified anything
and the NewLine is the new line, if so.
The format of the existing files is format 0, and we'll introduce new format numbers as we proceed,
just as with layout2layout. So the conversion from format 0 to format 1 will be huge; others will
generally be simple.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35426 a592a061-630c-0410-9148-cb99ea01b6c8
