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.
Completion uses a complicated async scheme based on timers to update
itself. This is probably not necessary anymore and is fragile to
event order changes.
This is what happens with the new painting scheme. Therefore the
asyncHideXXX() methods have to be made more robust and detect whether
completion state has changed by the time they are triggered.
When an image has to be loaded a second time and the cache
is not used or the image is not in the cache, its preview is
going to be regenerated again. Hence, if the same image
appears more than once on screen, avoid requesting simultaneous
generation of the same preview.
See also this thread:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg205057.html
This exception in the regex constructor is only theoretical (our regex
are hardcoded), but this is creating coverity noise.
Additionally, revert the following commits that are not needed anymore:
6b6fa94c: Catch exceptions to please coverity
c2ed75fd: Fixup 6b6fa94c: coverity says there are more possible exceptions.
This commit is better viewed with 'git show -b'.
This is detected when an undo group is open and contains at east one
element. This means indeed that changes are in progress. Note that the
group is in general opened in GuiApplication::dispatch. The code there
is changed to ensure that the group is closed before updating the
screen.
This patch is experimental. It is expected to be replaced in master by
a more complete solution. It could in the meantime be backported to 2.3.x.
Fixes bug #11159.
As Kornel pointed out, it's possible to give a command sequence, or
multiple "-x" arguments, and carry out an operation without actually
giving LyX a filename argument. This will lead to cases like:
lyx -batch -x buffer-export
which don't do anything, but it's not catastrophic.
The reordering of the code was incorrect. The code calling Change::paintCue()
has to come last, since it depends on the change_drawn value.
Spotted by coverity.
As of LaTeX2e 2018, characters are made active earlier, which results
in new expansion problems.
Following a suggestion of Markus Kohm (pc) and the TL mailing list [1],
we embrace non-ASCII input paths in \detokenize. This relies on e-tex,
but I think we can assume this is nowadays available everywhere.
[1] http://tug.org/pipermail/tex-live/2018-May/041691.htmlFixes: #11146
The code in 90cfe4ec3 only handled the cells which metrics are
computed directly, and missed those who were linearized inside a MathRow.
To fix this, we use the fact that all the positions in a math row have
the same height and make MathRow::metrics return a boolean indicating
whether it contains a caret for a given bufferview.
Fixes bug #11153.
Rather than checking for hardcoded title commands such as \maketitle,
use the titlename and titletype as defined in the layout.
This now also includes title environments.
Fixes part of #6461
This is an extra command used for sidenote citations. Since we do not
provide \cite with natbib (which tufte uses) as a choice, we use the
new AddToCiteEngine feature to add it.
File format change.
Fixes: #11150
Now layout files and modules can extend the cite engines or completely
overwrite them, and modify the cite formats.
Any CiteEngine definition in a layout/module will completely overwrite
those by cite engine files.
AddToCiteEngine will extend them (add if they do not exist yet).
Any CiteFormat definition in a layout will be preferred to those in cite
engines. CiteFormat definitions that are not touched by the former are
still active, though (so, as opposed to CiteEngine, a CiteFormat does
not completely overwrite those by the engine files).
Layout format change.
As opposed to modules (from which the framework was initially borrowed),
we only allow one cite engine per document. Thus, we don't need to fiddle
with lists.
