Yes. Changing the theme fixes the problem. It seems that the "windows11"
theme is the only one with this issue.
On Mon, Jul 8, 2024 at 4:49 PM LyX Ticket Tracker wrote:
> #13082: Tools | Preferences | Look & Feel | Display graphics | Preview
> size box
>
On 1/30/24 06:18, Pavel Sanda wrote:
On Mon, Jan 29, 2024 at 06:59:40PM -0500, Richard Kimberly Heck wrote:
Thanks for the tests. Enrico found a problem with file encodings that we
hope will fix this issue for RC2, but we will have to see. That will likely
be soon.
BTW it would be good to have
On Mon, Jan 29, 2024 at 06:59:40PM -0500, Richard Kimberly Heck wrote:
> Thanks for the tests. Enrico found a problem with file encodings that we
> hope will fix this issue for RC2, but we will have to see. That will likely
> be soon.
BTW it would be good to have RC2 out in mid Feb.
RC1 made it s
On 1/27/24 12:37, Pavel Sanda wrote:
On Sat, Jan 27, 2024 at 05:30:19PM +0100, didiergab...@free.fr wrote:
With this second version the pdf preview is also perfect !
Good, committed as 7eb5003a81ab. Will be part of RC2,
for your convenience you can leave the new configure.py
within your local R
On 1/29/24 13:30, didiergab...@free.fr wrote:
Hi,
I did some tests, because I don't always get the same behavior
depending on:
- The path leading to an svg file may or may not contain accents;
- depending on the way of inserting the svg graphic (direct insertion
from the toolbar icon, or with
On Sat, Jan 27, 2024 at 05:30:19PM +0100, didiergab...@free.fr wrote:
> With this second version the pdf preview is also perfect !
Good, committed as 7eb5003a81ab. Will be part of RC2,
for your convenience you can leave the new configure.py
within your local RC1 installation...
Pavel
--
lyx-dev
On Sat, Jan 27, 2024 at 06:05:02PM +0100, didiergab...@free.fr wrote:
> After setting up this version of the ???configure.py??? script I no longer
> find any trace of the file converter:
> PDF (graphic) ???> PNG with the command:
> ???pdftoppm -r 72 -png -singlefile $$i > $$o???
>
> Can you co
After setting up this version of the “configure.py” script I no longer find any
trace of the file converter:
PDF (graphic) —> PNG with the command:
“pdftoppm -r 72 -png -singlefile $$i > $$o”
Can you confirm that this is normal? (I tell myself that I may have clicked on
the “remove” button by
With this second version the pdf preview is also perfect !
- Mail original -
| On Sat, Jan 27, 2024 at 02:29:15PM +0100, Pavel Sanda wrote:
| > On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr
| > wrote:
| > > It's perfect ! See for yourself???
| >
| > Good. I will need to
ter image editor',
['gimp-remote', 'gimp'], rc_entry = [imageformats])
addToRC(imageformats % ((iv, ie)*10))
#
checkViewerEditor('a text editor', texteditors,
rc_entry = [r'''\Format asciichess asc"
On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr wrote:
> It's perfect ! See for yourself???
Good. I will need to prepare more generic patch for you to test.
Stay tuned,
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
ps :
But be careful, I'll come back with another question in a few minutes... On the
list of simple users... For a story about the background color of an svg
graphic... ;o)
- Mail original -
| It's perfect ! See for yourself…
| Thank’s
| Thank you so much !
| ps:
| - Mail orig
v', 'gwenview', 'kview',
'eog', 'xviewer', 'ristretto', 'gpicview', 'lximage-qt',
'xdg-open', 'gimp-remote', 'gimp'],
rc_entry = [imageformats])
path,
I see where the “cache” folder is located in my user directory here :
C:\Users\Didier\AppData\Roaming\LyX2.4\cache
And I just spotted the configure.py file here:
C:\Users\Didier\AppData\Local\Programs\LyX 2.4\Resources
So ok ?
- Mail original -
| On Sat, Jan 27, 2024 at 12:48:40P
On Sat, Jan 27, 2024 at 12:48:40PM +0100, didiergab...@free.fr wrote:
> I'm a little lost, because I managed the discussion threads very poorly and I
> didn't always place my comments in the right places...
Do not worry, we will manage.
> You would like the screenshot showing the preview of the
On Tue, Jan 23, 2024 at 09:22:23PM +0100, Thibaut Cuvelier wrote:
> On Tue, 23 Jan 2024 at 18:35, Pavel Sanda wrote:
>
> > On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
> > > pdftoppm -r 72 -png -singlefile $$i > $$o
> >
> > This is new route in 2.4 which can be used
On Tue, 23 Jan 2024 at 18:35, Pavel Sanda wrote:
> On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
> > pdftoppm -r 72 -png -singlefile $$i > $$o
>
> This is new route in 2.4 which can be used to avoid IM problems in linux.
> We perhaps triggerred unnecessary problems o
On 1/23/24 12:33, Pavel Sanda wrote:
On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
pdftoppm -r 72 -png -singlefile $$i > $$o
This is new route in 2.4 which can be used to avoid IM problems in linux.
We perhaps triggerred unnecessary problems on Windows.
This could
On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
> pdftoppm -r 72 -png -singlefile $$i > $$o
This is new route in 2.4 which can be used to avoid IM problems in linux.
We perhaps triggerred unnecessary problems on Windows.
This could be sovled by making pdftoppm addition
66): svgz,
frontends\qt4\GuiApplication.cpp (266): tif,
frontends\qt4\GuiApplication.cpp (266): tiff,
frontends\qt4\GuiApplication.cpp (266): wbmp,
frontends\qt4\GuiApplication.cpp (266): webp,
frontends\qt4\GuiApplication.cpp (266): xbm,
frontends\qt4\GuiApplication.cpp (266): x
On 1/23/24 04:06, didiergab...@free.fr wrote:
I am currently in front of my Windows 10 PC at my workplace with which
I am experiencing exactly the same symptoms.
I followed your instructions, and you will find the requested file
attached.
I will do the same thing again this evening at home, with
On Tue, Jul 18, 2023 at 10:04:03PM +0200, Christoph Schmitz wrote:
> In the meantime, this problem has been fixed. However, due to a compiler
> error, I can currently no longer compile LyX on macOS.
Fixed where?
We did not commit the fix yet. (But perhaps you don't use Qt 6.3.1 on platform
cocoa
In the meantime, this problem has been fixed. However, due to a compiler error,
I can currently no longer compile LyX on macOS.
> Am 18.07.2023 um 16:25 schrieb LyX Ticket Tracker :
>
> #12576: [Bug report] "Insert graphics" does not work an
Hello skostysh,
Sorry, I did not know that.
Best wishes,
Chris
> Am 28.10.2022 um 17:50 schrieb LyX Ticket Tracker :
>
> #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]
> -+-
> Reporter
Yes, I am.
Von meinem iPhone gesendet
> Am 27.10.2022 um 21:40 schrieb LyX Ticket Tracker :
>
> #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]
> -+-
> Reporter: docc | Owner: lasgo
On Mon, Oct 03, 2022 at 12:27:00PM -0400, Scott Kostyshak wrote:
> Is this by design? Would a patch that preserves '~' be considered?
Sounds reasonable to me from the linux perspective. What we do with ~ in
windows?
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/ma
On Mon, Oct 10, 2022 at 05:06:20PM +0200, Christoph Schmitz wrote:
> For some time now, "Insert graphics" no longer works in my self-compiled
> version of LyX 2.4. The window opens and I can search for a file. When I
> click on "Open", the window disappears, but the
For some time now, "Insert graphics" no longer works in my self-compiled
version of LyX 2.4. The window opens and I can search for a file. When I click
on "Open", the window disappears, but the graphic file is not inserted. It
seems to be a problem with the "file pic
Sometimes I need an absolute path, but I still want to use '~' since I
have different user names on different computers.
LyX lets me insert '~' and finds the file but expands the path (i.e.,
replaces '~' with '/home/scott', so the path won't work on my other
computer.
Is this by design? Would a p
On Mon, Sep 26, 2022 at 12:05:13PM +0200, Jean-Marc Lasgouttes wrote:
> Le 23/09/2022 à 21:43, Scott Kostyshak a écrit :
> > Pavel gave some helpful direction regarding where concurrency might be
> > especially helpful: graphics conversion.
>
> Note that when we go this
Le 23/09/2022 à 21:43, Scott Kostyshak a écrit :
Pavel gave some helpful direction regarding where concurrency might be
especially helpful: graphics conversion.
Note that when we go this way, we will have to require gcc 5 in order to
obtain thread safety for std::string. The alternative would
On Sun, Sep 25, 2022 at 11:13:54PM +0200, Jean-Marc Lasgouttes wrote:
> Le 25/09/2022 à 22:26, Pavel Sanda a écrit :
> > On Sat, Sep 24, 2022 at 05:07:33PM -0400, Scott Kostyshak wrote:
> > > That sounds right. I think it probably makes sense to change the design.
> >
> > Yep, looks like that.
> >
Le 25/09/2022 à 22:26, Pavel Sanda a écrit :
On Sat, Sep 24, 2022 at 05:07:33PM -0400, Scott Kostyshak wrote:
That sounds right. I think it probably makes sense to change the design.
Yep, looks like that.
First I want to read about 'nod', which apparently is a library that we
include and use
On Sat, Sep 24, 2022 at 05:07:33PM -0400, Scott Kostyshak wrote:
> That sounds right. I think it probably makes sense to change the design.
Yep, looks like that.
> First I want to read about 'nod', which apparently is a library that we
> include and use.
It would also make sense to look at QThre
On Sat, Sep 24, 2022 at 10:06:36PM +0200, Pavel Sanda wrote:
> On Sat, Sep 24, 2022 at 02:11:36PM -0400, Scott Kostyshak wrote:
> > Each iteration of the while loop constructs a new ForkedCall instance.
> > call.startScript() then forks the process.
>
> I see now, you are right. If I understand th
On Sat, Sep 24, 2022 at 02:11:36PM -0400, Scott Kostyshak wrote:
> Each iteration of the while loop constructs a new ForkedCall instance.
> call.startScript() then forks the process.
I see now, you are right. If I understand the logic now (basically each loop
iteration triggering new callNext via
On Sat, Sep 24, 2022 at 05:20:49PM +0200, Pavel Sanda wrote:
> On Sat, Sep 24, 2022 at 05:18:53PM +0200, Pavel Sanda wrote:
> > naively expect new ForkedCall for each conversion, no?
>
> for each *thread*, not conversion
Thanks for taking a look.
Each iteration of the while loop constructs a new
On Sat, Sep 24, 2022 at 05:18:53PM +0200, Pavel Sanda wrote:
> naively expect new ForkedCall for each conversion, no?
for each *thread*, not conversion
> Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Fri, Sep 23, 2022 at 03:43:05PM -0400, Scott Kostyshak wrote:
> The reason I send this preliminary patch in is to (1) see if there is at
> least preliminary support for this kind of code change;
If I understand correctly you use single variable ForkedCall call;
for all conversions done in para
On Sat, Sep 24, 2022 at 02:57:31PM +0200, Kornel Benko wrote:
> Am Fri, 23 Sep 2022 15:43:05 -0400
> schrieb Scott Kostyshak :
>
> > Pavel gave some helpful direction regarding where concurrency might be
> > especially helpful: graphics conversion.
> >
> > Att
Am Fri, 23 Sep 2022 15:43:05 -0400
schrieb Scott Kostyshak :
> Pavel gave some helpful direction regarding where concurrency might be
> especially helpful: graphics conversion.
>
> Attached is a work-in-progress patch, as well as an example file.
>
> When testing with the
Pavel gave some helpful direction regarding where concurrency might be
especially helpful: graphics conversion.
Attached is a work-in-progress patch, as well as an example file.
When testing with the attached document, remember to clear the cache in
your user directory before opening LyX. For
Also,
wouldn't embedding graphics introduce extra work if the source
graphic was changed? For instance, if I embedded a plot, then later
changed data an reran the plot, I would need to manually update the
LyX file.
I am completely with you, but I think if we could support both (as I
sketched i
Am Sun, 3 Oct 2021 11:29:02 -0400
schrieb "Paul A. Rubin" :
> On 10/3/21 11:08 AM, Jürgen Spitzmüller wrote:
> > Am Sonntag, dem 03.10.2021 um 10:48 -0400 schrieb Paul A. Rubin:
> >> Personally, I'd prefer to keep LyX files small and plain text. Also,
> >
On 10/3/21 11:08 AM, Jürgen Spitzmüller wrote:
Am Sonntag, dem 03.10.2021 um 10:48 -0400 schrieb Paul A. Rubin:
Personally, I'd prefer to keep LyX files small and plain text. Also,
wouldn't embedding graphics introduce extra work if the source
graphic was changed? For instance, if I
Am Sonntag, dem 03.10.2021 um 10:48 -0400 schrieb Paul A. Rubin:
> Personally, I'd prefer to keep LyX files small and plain text. Also,
> wouldn't embedding graphics introduce extra work if the source
> graphic was changed? For instance, if I embedded a plot, then later
> cha
er to keep LyX files small and plain text. Also,
wouldn't embedding graphics introduce extra work if the source graphic
was changed? For instance, if I embedded a plot, then later changed data
an reran the plot, I would need to manually update the LyX file.
The LyX Archive export seems to be a
On Sun, Oct 03, 2021 at 09:49:34AM +0200, Jürgen Spitzmüller wrote:
> As to the request here, this would have the (severe) drawback that the
> LyX file is no longer a plain text file.
I really don't know much about this, but couldn't we use some sort of ASCII
encoding like base64 (https://en.wik
Am Samstag, dem 02.10.2021 um 20:42 -0400 schrieb Scott Kostyshak:
> On Sat, Oct 02, 2021 at 06:09:03PM -0500, javier ignacio carrero
> mantilla wrote:
> > A suggestion for lyx development: to change the file format in
> > such a way
> > that it includes the graphics, as
On Sat, Oct 02, 2021 at 06:09:03PM -0500, javier ignacio carrero mantilla wrote:
> A suggestion for lyx development: to change the file format in such a way
> that it includes the graphics, as word processors do. For example: pasting
> myGraphic.png into myDocument.lyx makes i
A suggestion for lyx development: to change the file format in such a way
that it includes the graphics, as word processors do. For example: pasting
myGraphic.png into myDocument.lyx makes it part of myDocument.lyx
structure.
The current need to move, copy, paste, or e-mail all graphics alongside
On Thu, Jan 21, 2021 at 11:38:25AM -0500, Neal Becker wrote:
> In inserted graphics, we can select a page from a multi-page pdf using
> "latex and lyx options". This will show the correct graphics in the
> pdf output. But the preview always shows page 1. Would be nice to
&g
In inserted graphics, we can select a page from a multi-page pdf using
"latex and lyx options". This will show the correct graphics in the
pdf output. But the preview always shows page 1. Would be nice to
implement something to fix the preview.
--
Those who don't understan
On Friday, January 8, 2021 4:05:39 PM WET Jean-Marc Lasgouttes wrote:
> I have no idea about that, but I am the kind of guy who thinks that we
> do not care about dvi file...
IIRC the preview mechanism used the dvi output.
I am quite happy to use the preview even although I do not know how this
w
Le 08/01/2021 à 16:50, José Abílio Matos a écrit :
On Tuesday, January 5, 2021 5:10:13 PM WET Jean-Marc Lasgouttes wrote:
> José, what is the status on this?
Honestly? Since I am not masochist I do not play with hornets nests. :-)
So as far I remember the issue is: is there any reason in 2021
On Tuesday, January 5, 2021 5:10:13 PM WET Jean-Marc Lasgouttes wrote:
> Le 13/06/2019 à 17:41, José Abílio Matos a écrit :
> > Last week while working with python2/python3 differences I found clues
> > that
> > the legacy graphics conversion has problems.
> >
> &g
Le 13/06/2019 à 17:41, José Abílio Matos a écrit :
Last week while working with python2/python3 differences I found clues that
the legacy graphics conversion has problems.
Like I said in bugs #11457 and #11282:
"This also means that the legacy conversion has some issues but I think that
b
Le 13/11/2019 à 16:03, Neven Sajko a écrit :
I will not have time to debug this for a few more weeks, probably, but
here is something I found on the Web, could maybe be relevant:
https://github.com/tallforasmurf/CHIP8IDE/issues/22
TLDR: Somebody had a similar problem and fixed it by adding two
As far as I understand, this could indeed be a Xorg, graphics driver
or QT bug ... I suppose someone more knowledgeable about X11 and Xorg
could infer some useful conclusions from the fact that the bug does
not appear in the screencasts.
Neven
--
lyx-devel mailing list
lyx-devel@lists.l
I will not have time to debug this for a few more weeks, probably, but
here is something I found on the Web, could maybe be relevant:
https://github.com/tallforasmurf/CHIP8IDE/issues/22
TLDR: Somebody had a similar problem and fixed it by adding two QT
calls after the QT Widget update() call. Tha
Le 13/11/2019 à 00:51, Neven Sajko a écrit :
It is only the LyX work area that is not updated or the whole window
(toolbar, menus...)?
I am not sure what do you mean by "work area", but for me (while I am
looking at the Xorg-powered display and using lyx), there are problems
on almost the whole
On Tue, Nov 12, 2019 at 11:51:29PM +, Neven Sajko wrote:
> This might explain why this bug
> would only become apparent when using Lyx alongside a minimal WM like
> DWM or without a WM (I usually use Lyx-like applications so they are
> almost full screen).
I tried to install dwm in oldstable d
> It is only the LyX work area that is not updated or the whole window
> (toolbar, menus...)?
I am not sure what do you mean by "work area", but for me (while I am
looking at the Xorg-powered display and using lyx), there are problems
on almost the whole window. The little animations that should h
Le 10/11/2019 à 22:32, Neven Sajko a écrit :
Note: Am am resending this message now, I already sent it yesterday,
but it did was not approved.
Hello,
I am currently moderating the list until we find a way to avoid spam
more efficiently. I am not yet up-to-speed with the new list software we
This is on an up-to-date Archlinux system which should mean all
software is at latest release version.
Software versions:
lyx 2.3.3, qt5 5.13.2, xorg 1.20.5
Reproducing: Create an empty HOME dir and .lyx in it, run
/usr/share/lyx/configure.py with python2, start Lyx with created HOME.
I tried u
Note: Am am resending this message now, I already sent it yesterday,
but it did was not approved.
This is on an up-to-date Archlinux system which should mean all
software is at latest release version.
Software versions:
lyx 2.3.3, qt5 5.13.2, xorg 1.20.5
Reproducing: Create an empty HOME dir an
Le 13/06/2019 à 17:41, José Abílio Matos a écrit :
Last week while working with python2/python3 differences I found clues that
the legacy graphics conversion has problems.
Like I said in bugs #11457 and #11282:
"This also means that the legacy conversion has some issues but I think that
b
Le 13/06/2019 à 17:41, José Abílio Matos a écrit :
Last week while working with python2/python3 differences I found clues that
the legacy graphics conversion has problems.
Like I said in bugs #11457 and #11282:
"This also means that the legacy conversion has some issues but I think that
b
On Friday, 14 June 2019 07.33.33 WEST Enrico Forestieri wrote:
> s/rsvg-convert/pdftocairo/
I have. But I want to test all the available scenarios to understand what is
going on.
The purpose of this thread is to understand what are the minimum requirements
for instant preview and to fix the co
On Fri, Jun 14, 2019 at 08:28:09AM +0200, Enrico Forestieri wrote:
> On Fri, Jun 14, 2019 at 07:09:27AM +0100, José Abílio Matos wrote:
> >
> > In terms of speed, the conversion is slow.
>
> Do you have rsvg-convert installed?
s/rsvg-convert/pdftocairo/
--
Enrico
d clues
> > > that
> > > the legacy graphics conversion has problems.
> >
> > Which kind of problems?
>
> In terms of speed, the conversion is slow.
Do you have rsvg-convert installed?
> > > Like I said in bugs #11457 and #11282:
> > > "This al
On Friday, 14 June 2019 06.59.16 WEST Enrico Forestieri wrote:
> On Thu, Jun 13, 2019 at 04:41:44PM +0100, José Abílio Matos wrote:
> > Last week while working with python2/python3 differences I found clues
> > that
> > the legacy graphics conversion has problems.
>
>
On Thu, Jun 13, 2019 at 04:41:44PM +0100, José Abílio Matos wrote:
> Last week while working with python2/python3 differences I found clues that
> the legacy graphics conversion has problems.
Which kind of problems?
> Like I said in bugs #11457 and #11282:
> "This also mean
Last week while working with python2/python3 differences I found clues that
the legacy graphics conversion has problems.
Like I said in bugs #11457 and #11282:
"This also means that the legacy conversion has some issues but I think that
by now everyone should be using dvipng to that part o
Am Sonntag, den 17.02.2019, 20:28 +0200 schrieb Jerry:
> wישא ןמכםרצשאןםמ ?
I beg your pardon?
Jürgen
signature.asc
Description: This is a digitally signed message part
wישא ןמכםרצשאןםמ ?
On Wed, Feb 13, 2019 at 5:02 PM LyX Ticket Tracker wrote:
> #11483: Ver. 3.2.3 17 May 2018 -- Problem with inserting Graphics into
> Figure
> float when AVAST Anti virus is installed
> -+--
> Reporter: dag
On Mon, Nov 12, 2018 at 03:09:13PM +0100, Pavel Sanda wrote:
> The security problems of ghostscript which caused the policy restrictions
> were
> fixed with the release of ghostscript 9.25 (released 2018-09-13).
> I quickly looked at ubuntu packages and 18.04 already ships 9.25, so
> it would be
the PPA, and installed LyX from that -- it now seems
> > > to work.
> > >
> > > I do, however, have an odd problem where graphics often don't display in
> > > LyX, giving errors such as "error loading file into memory" or "error
> > &
in wrote:
>>>>> On 11/10/18 9:45 PM, Baris Erkus wrote:
>>>>>> Hello,
>>>>>>
>>>>>> PDF graphics appears to be blurred in LyX when scaled from Graphics
>>>>>> Options --> LaTeX and LyX options --> Show in L
; > I do, however, have an odd problem where graphics often don't display in
> > LyX, giving errors such as "error loading file into memory" or "error
> > converting to loadable format" which I didn't get before upgrading to
> > Ubuntu 18.04
On 11/5/18 2:32 PM, Jeff Defoe wrote:
I realized I was using the Lyx from the Ubuntu repository. When I
removed it, added the PPA, and installed LyX from that -- it now seems
to work.
I do, however, have an odd problem where graphics often don't display
in LyX, giving errors such as &
I realized I was using the Lyx from the Ubuntu repository. When I removed
it, added the PPA, and installed LyX from that -- it now seems to work.
I do, however, have an odd problem where graphics often don't display in
LyX, giving errors such as "error loading file into memory&
On 11/2/18, Richard Kimberly Heck wrote:
> Unfortunately, without debug symbols, the backtrace is unreadable. I
> don't know if there is an Ubuntu package that would allow you to install
> them.
If the OP is using the LyX PPA, try to install the lyx-dbg package,
which should give the debugging sy
Can you describe better what triggers this bug?
Unfortunately, without debug symbols, the backtrace is unreadable. I
don't know if there is an Ubuntu package that would allow you to install
them. But you could also try compiling from source with --enable-debug.
Riki
On 11/1/18 9:20 PM, Jeff De
( 1) lyx: lyx() [0x8de95d]
( 2) lyx: lyx() [0x8b]
( 3) lyx: lyx() [0x5a13dc]
( 4) /lib/x86_64-linux-gnu/libc.so.6:
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f83f8afaf20]
( 5) lyx: lyx() [0x902e5d]
( 6) lyx: lyx() [0x90164c]
( 7) lyx: lyx() [0x90b451]
( 8) lyx: lyx() [0x6e9d1b]
( 9)
gt; > > :
> > > > On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote:
> > > > > The graphics display looks wrong if cache is enabled.
> > > > > Attached versions of oxygen fonts.svgz.
> > > > > (Master and 2.3.x show the same
Benko wrote:
> > > > The graphics display looks wrong if cache is enabled.
> > > > Attached versions of oxygen fonts.svgz.
> > > > (Master and 2.3.x show the same behavior)
> > > > (Some cropping error on the upper side?)
> > >
> > &g
Am Donnerstag, 14. Juni 2018 03:01:51 CEST schrieb Scott Kostyshak
:
> On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote:
> > The graphics display looks wrong if cache is enabled.
> > Attached versions of oxygen fonts.svgz.
> > (Master and 2.3.x show the sam
On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote:
> The graphics display looks wrong if cache is enabled.
> Attached versions of oxygen fonts.svgz.
> (Master and 2.3.x show the same behavior)
> (Some cropping error on the upper side?)
What are the steps to repro
Richard Kimberly Heck wrote:
> On 06/07/2018 02:56 AM, Pavel Sanda wrote:
> > Scott Kostyshak wrote:
> >> This is the same issue as discussed here:
> >>
> >> https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64
> > Indeed, when the patch in master is applied to branch the problem
On 06/07/2018 02:56 AM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> This is the same issue as discussed here:
>>
>> https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64
> Indeed, when the patch in master is applied to branch the problem is gone.
I guess we'd better apply that
Scott Kostyshak wrote:
> This is the same issue as discussed here:
>
> https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64
Indeed, when the patch in master is applied to branch the problem is gone.
Pavel
On Wed, Jun 06, 2018 at 09:49:09PM +, Pavel Sanda wrote:
> Taking back. To correctly reproduce the problem, one needs to empty the
> image cache. Bisect then leads to:
>
> commit a1579c583acb22a7f5dae80a9bfe7707774f49a4
This is the same issue as discussed here:
https://www.mail-archive.com
fixes are simple and on line with the changes made during
> > the 2.3 development. It was an oversight to leave them out.
> >
> > With this commit all the python scripts should be supported by
> > python 2 and 3.
>
> Jose, after this patch I have tr
The graphics display looks wrong if cache is enabled.
Attached versions of oxygen fonts.svgz.
(Master and 2.3.x show the same behavior)
(Some cropping error on the upper side?)
Kornel
signature.asc
Description: This is a digitally signed message part.
On Wed, May 02, 2018 at 08:40:14PM +, Pavel Sanda wrote:
> Pavel Sanda wrote:
> > > go ahead and commit your current code and I will make the extension.
> >
> > Ok, will commit once back home.
>
> It's in the tree, feel free to modify or kill the routines for what you
> need...
OK sounds go
Pavel Sanda wrote:
> > go ahead and commit your current code and I will make the extension.
>
> Ok, will commit once back home.
It's in the tree, feel free to modify or kill the routines for what you need...
Pavel
Scott Kostyshak wrote:
> current call faster on large documents. e.g. you could change
>
> cur.countInsetsInSelection(GRAPHICS_CODE)>1)
>
> to
>
> cur.countInsetsInSelection(GRAPHICS_CODE, 2) == 2
>
> If you are not having fun, I would be happy to make this change (but
That would be nice.
e a crussade against useless items in context menu.
> > >
> > > Shouldn't it appear only if there are at least two graphics insets?
> >
> > Like this. I can keep the first routine if there is an interest (count>0 is
> > slower).
> > Pavel
>
>
Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
> >> Would this patch make you happy?
> >> The routine itself could be used for different type of insets if you
> >> intend to make a crussade against useless items in context menu.
> >
> > Shouldn't it
1 - 100 of 1962 matches
Mail list logo
