Uses the correct shortcuts from lib/bind/sk/menus.bind, but fails nonetheless
because the regex for advanced search cannot find the correct list type.
(That is: it cannot distinguish between 'enumerate', 'itemize', 'labeling', etc.)
The goal of this patch is to make "self-insert <string>" act as a
sequence of individual self-insert calls. Once it is done, the
insertion of the commit string in GuiWorkArea can use that, which
fixes the issues described in bug 11183.
1/ in InsetMathNest, SELF_INSERT is rewritten to be a proper loop of
interpretChar, instead of inserting the string as characters. This
solves the issue of interpreting ^ properly.
2/ the text version does not need to be changed (the loop is rewritten
using a range, though).
3/ Then {{{GuiWorkArea::inputMethodEvent}}} is changed to invoke
directly self-insert. This removes the update issues.
Fixes bug 11183.
Otherwise it will be recognized only by the file extension, because
libmagic returns "application/octet-stream" as mime type. Moreover,
if the emf encapsulates a binary image format, it can be confused
with this other format and its preview on screen fails.
In such filesystems, including either Magic.h or magic.h does not
make any difference and the one or other file is included depending
on the search order. In this case, Magic.h was trying to include
itself instead of including magic.h.
This makes the code much easier to read and, additionally, allows to
parse the magic file with magic_load() only once per session.
As a result, getFormatFromFile is slightly faster.
This is not perfect, since variable width columns will break at a certain
treshold, but it is better than what we have now (no tabular width
indication at all)
This effectively enables linebreaks, multipars and layout changes in
non-fixed width (i.e., standard) table columns.
Fixes: #6577
TODO: metrics are wrong (too wide) on screen with linebreaks.
When a raster image with an advertised pixel density different
from 72 dpi is included in a latex file, the output image dimensions
are scaled by the ratio 72/pixel_density. Hence, if a clipping
bounding box is specified, it has to be scaled by the same ratio,
otherwise the images will be clipped differently on screen and output.
Here we use the extractbb command (present in any TeX distribution)
to ask about the output dimensions of the image as dictated by the
pixel density and compute the scaling ratio by the knowledge of the
actual dimensions. If, for whatever reason, extractbb is not found,
everything goes as before, because the clipping bounding box will
simply not be corrected.
