Re: \Omega is not displayed correctly

[Scott Kostyshak]

On Thu, Jul 21, 2016 at 02:00:15PM -0600, L. Han wrote:
> After update to 2.2.0, \Omega is not displayed correctly in Lyx. It looks
> like a bold \neg now. Hope it will be fixed soon. Thanks!

Hi Han, thanks for this report. For reports like this it's always
helpful if you give your OS.

Also, which LyX version did you use before upgrading to 2.2.0?

Thanks,

Scott


signature.asc
Description: PGP signature

LyX 2.2.1 Tarballs

[Richard Heck]

Source tarballs for LyX 2.2.1 have been uploaded to
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/2.2.1/. Please prepare binaries.

Richard

\Omega is not displayed correctly

[L. Han]

After update to 2.2.0, \Omega is not displayed correctly in Lyx. It looks
like a bold \neg now. Hope it will be fixed soon. Thanks!

Re: Ticket #10304 : Instant Preview: Too much horizontal space

[Jean-Marc Lasgouttes]

Le 21/07/2016 à 19:10, Scott Kostyshak a écrit :

On Thu, Jul 21, 2016 at 04:32:09PM +0200, Jean-Marc Lasgouttes wrote:


I'd be interested to have input at this point.


No input but I'll be happy to test when you have a patch. It seems like
one of those things that we'll just have to test to see if there are
issues.


I wanted to put this on trac, but the web site seems to be under heavy 
load. Restarting httpd did not help.


JMarc



>From 467099841cda86ab942e4400d348b3637f854063 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 21 Jul 2016 20:16:27 +0200
Subject: [PATCH] Remove horizontal spacing around previews

This concerns the preview version of InsetPreview and InsetIPA.

Fixes bug #10304.
---
 src/insets/InsetIPA.cpp | 9 +++--
 src/insets/InsetPreview.cpp | 5 +
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/src/insets/InsetIPA.cpp b/src/insets/InsetIPA.cpp
index 3876358..84caac2 100644
--- a/src/insets/InsetIPA.cpp
+++ b/src/insets/InsetIPA.cpp
@@ -151,7 +151,7 @@ void InsetIPA::reloadPreview(DocIterator const & pos) const
 void InsetIPA::draw(PainterInfo & pi, int x, int y) const
 {
 	if (previewState(pi.base.bv)) {
-		preview_->draw(pi, x + TEXT_TO_INSET_OFFSET, y);
+		preview_->draw(pi, x, y);
 		setPosCache(pi, x, y);
 		return;
 	}
@@ -181,15 +181,12 @@ void InsetIPA::metrics(MetricsInfo & mi, Dimension & dim) const
 {
 	if (previewState(mi.base.bv)) {
 		preview_->metrics(mi, dim);
-		mi.base.textwidth += 2 * TEXT_TO_INSET_OFFSET;
-		
+
 		dim.wid = max(dim.wid, 4);
 		dim.asc = max(dim.asc, 4);
-		
+
 		dim.asc += TEXT_TO_INSET_OFFSET;
 		dim.des += TEXT_TO_INSET_OFFSET;
-		dim.wid += TEXT_TO_INSET_OFFSET;
-		dim.wid += TEXT_TO_INSET_OFFSET;
 		// insert a one pixel gap
 		dim.wid += 1;
 		// Cache the inset dimension.
diff --git a/src/insets/InsetPreview.cpp b/src/insets/InsetPreview.cpp
index 53cfb23..334a8f2 100644
--- a/src/insets/InsetPreview.cpp
+++ b/src/insets/InsetPreview.cpp
@@ -138,7 +138,7 @@ void InsetPreview::draw(PainterInfo & pi, int x, int y) const
 {
 	if (previewState(pi.base.bv)) {
 		// one pixel gap in front
-		preview_->draw(pi, x + 1 + TEXT_TO_INSET_OFFSET, y);
+		preview_->draw(pi, x + 1, y);
 		setPosCache(pi, x, y);
 	} else
 		InsetText::draw(pi, x, y);
@@ -167,15 +167,12 @@ void InsetPreview::metrics(MetricsInfo & mi, Dimension & dim) const
 {
 	if (previewState(mi.base.bv)) {
 		preview_->metrics(mi, dim);
-		mi.base.textwidth += 2 * TEXT_TO_INSET_OFFSET;
 
 		dim.wid = max(dim.wid, 4);
 		dim.asc = max(dim.asc, 4);
 
 		dim.asc += TEXT_TO_INSET_OFFSET;
 		dim.des += TEXT_TO_INSET_OFFSET;
-		dim.wid += TEXT_TO_INSET_OFFSET;
-		dim.wid += TEXT_TO_INSET_OFFSET;
 		// insert a one pixel gap
 		dim.wid += 1;
 		// Cache the inset dimension.
-- 
2.7.4

Re: Ticket #10304 : Instant Preview: Too much horizontal space

[Andrew Parsloe]

On 22/07/2016 10:02 a.m., Scott Kostyshak wrote:

On Thu, Jul 21, 2016 at 08:37:06PM +0200, Jean-Marc Lasgouttes wrote:


I wanted to put this on trac, but the web site seems to be under heavy load.
Restarting httpd did not help.


It looks like a nice improvement to me in limited testing.

Scott

I can't check on trac at the moment, but I think the extra space 
referred to is that introduced, perhaps a couple of years ago, as a 
safety measure so that empty previews would be visible. I think Richard 
did the work. (The space annoys me, but an empty preview *is* visible.)


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: \Omega is not displayed correctly

[Richard Heck]

On 07/21/2016 06:05 PM, Scott Kostyshak wrote:
> On Thu, Jul 21, 2016 at 04:29:32PM -0400, Richard Heck wrote:
>> But I can't access trac right now
> Same here.

I'm not sure what the problem is. CPU load is low. Bandwidth, possibly.
I think we are on a shared server, too, so who knows what others' loads
are like.

Richard

Re: \Omega is not displayed correctly

[Jean-Marc Lasgouttes]

Le 22/07/2016 à 00:10, Richard Heck a écrit :

On 07/21/2016 06:05 PM, Scott Kostyshak wrote:

On Thu, Jul 21, 2016 at 04:29:32PM -0400, Richard Heck wrote:

But I can't access trac right now

Same here.


I'm not sure what the problem is. CPU load is low. Bandwidth, possibly.
I think we are on a shared server, too, so who knows what others' loads
are like.


Here is what top says. Doesn't it mean that we swap a lot? Where can I 
see the requests at a given point?


JMarc

top - 00:49:38 up 146 days, 13:54,  2 users,  load average: 14.19, 14.28, 14
Tasks: 121 total,   1 running, 119 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.7%us,  0.3%sy,  0.0%ni,  0.0%id, 99.0%wa,  0.0%hi,  0.0%si,  0.0%
Mem:   1536156k total,  1469976k used,66180k free, 1640k buffers
Swap:  1015804k total,   909412k used,   106392k free,38132k cached

Re: Ticket #10304 : Instant Preview: Too much horizontal space

[Scott Kostyshak]

On Thu, Jul 21, 2016 at 08:37:06PM +0200, Jean-Marc Lasgouttes wrote:

> I wanted to put this on trac, but the web site seems to be under heavy load.
> Restarting httpd did not help.

It looks like a nice improvement to me in limited testing.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Fix CAS input on windows (bug 10262)

[Scott Kostyshak]

On Sat, Jul 02, 2016 at 10:10:00PM -0400, Scott Kostyshak wrote:
> On Sat, Jul 02, 2016 at 06:59:46PM +0200, Georg Baum wrote:
> > commit 6dfc255088ecd3393c4c5dc3d2c5357a3fbabfc0
> > Author: Georg Baum 
> > Date:   Sat Jul 2 18:58:30 2016 +0200
> > 
> > Fix CAS input on windows (bug 10262)
> > 
> > This is the well known file locking problem: The TempFile class keeps 
> > the
> > created file locked for the own process, and this prevents the CAS to 
> > read it.
> > ---
> >  src/mathed/MathExtern.cpp |9 +++--
> >  1 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/mathed/MathExtern.cpp b/src/mathed/MathExtern.cpp
> > index b3443fa..8b1e0f0 100644
> > --- a/src/mathed/MathExtern.cpp
> > +++ b/src/mathed/MathExtern.cpp
> > @@ -1001,8 +1001,13 @@ namespace {
> > {
> > // In order to avoid parsing problems with command interpreters
> > // we pass input data through a file
> > -   TempFile tempfile("casinput");
> > -   FileName const cas_tmpfile = tempfile.name();
> > +   // Since the CAS is supposed to read the temp file we need
> > +   // to unlock it on windows (bug 10262).
> > +   unique_ptr tempfile(new TempFile("casinput"));
> > +   tempfile->setAutoRemove(false);
> > +   FileName const cas_tmpfile = tempfile->name();
> > +   tempfile.reset();
> > +
> > if (cas_tmpfile.empty()) {
> > lyxerr << "Warning: cannot create temporary file."
> ><< endl;
> 
> Any chance that similar fixes could fix the following two bugs?
> http://www.lyx.org/trac/ticket/10043
> http://www.lyx.org/trac/ticket/10091

Georg, I'd be curious if you think a similar fix could fix #10043 and
#10091.

Scott


signature.asc
Description: PGP signature

Re: \Omega is not displayed correctly

[Richard Heck]

On 07/21/2016 06:50 PM, Jean-Marc Lasgouttes wrote:
> Le 22/07/2016 à 00:10, Richard Heck a écrit :
>> On 07/21/2016 06:05 PM, Scott Kostyshak wrote:
>>> On Thu, Jul 21, 2016 at 04:29:32PM -0400, Richard Heck wrote:
 But I can't access trac right now
>>> Same here.
>>
>> I'm not sure what the problem is. CPU load is low. Bandwidth, possibly.
>> I think we are on a shared server, too, so who knows what others' loads
>> are like.
>
> Here is what top says. Doesn't it mean that we swap a lot? Where can I
> see the requests at a given point?
>
> JMarc
>
> top - 00:49:38 up 146 days, 13:54,  2 users,  load average: 14.19,
> 14.28, 14
> Tasks: 121 total,   1 running, 119 sleeping,   0 stopped,   1 zombie
> Cpu(s):  0.7%us,  0.3%sy,  0.0%ni,  0.0%id, 99.0%wa,  0.0%hi, 
> 0.0%si,  0.0%
> Mem:   1536156k total,  1469976k used,66180k free, 1640k buffers
> Swap:  1015804k total,   909412k used,   106392k free,38132k cached

Well, things seem to have settled down

rh

Re: Ticket #10304 : Instant Preview: Too much horizontal space

[Andrew Parsloe]

On 22/07/2016 10:52 a.m., Jean-Marc Lasgouttes wrote:

Le 22/07/2016 à 00:15, Andrew Parsloe a écrit :

I can't check on trac at the moment, but I think the extra space
referred to is that introduced, perhaps a couple of years ago, as a
safety measure so that empty previews would be visible. I think Richard
did the work. (The space annoys me, but an empty preview *is* visible.)


This code was present at the introduction of the preview inset.

JMarc


I was thinking of http://www.lyx.org/trac/ticket/7522 (e.g. comment 11). 
My memory is that the spacing increased after that ticket.


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Compiling with Microsoft Visual C++

[Kornel Benko]

Am Donnerstag, 21. Juli 2016 um 16:32:14, schrieb racoon 
> On 21.07.2016 08:51, Kornel Benko wrote:
> > Am Donnerstag, 21. Juli 2016 um 08:23:51, schrieb racoon 
> >> On 20.07.2016 14:02, Kornel Benko wrote:
> >>> Am Mittwoch, 20. Juli 2016 um 11:26:47, schrieb racoon 
>  Each time I build a number of .gmo-files, like ar.gmo, are generated
>  which takes some time.
> 

...

>  I can turn of the warning using the environment variable but that just
>  gets rid of the messages not the generating process.
> 
>  Does someone know what that is and whether I can do something about it?
> 
>  Daniel
> >>>
> >>> You use '-DLYX_NLS=ON', this is the default.
> >>>
> >>> *.po: Text files containing ui-translations (e.g. 'de.po' for German)
> >>> *.gmo: the associated compiled files interpreted later by lyx.
> >>
> >> Thanks. Not sure I understood though.
> >>
> >> I disabled "LYX_NLS" in CMake (could not find any flags containing
> >> "DLYX"). But when compiling the .gmo files are still generated. So the
> >> flag seems to have no effect on this.
> >
> > This is because you use the cmake-GUI.
> > From the command line your cmake call should contain '-DLYX_NLS=OFF'.
> >
> > The gmo-files are created (respectively copied from source if you don't 
> > have gettext executables)
> > in the subdirectory po. But with NLS disabled, this directory will newer be 
> > entered. See CMakeLists.txt:713
> >
> > But stop ... I see, that if you set LYX_INSTALL, then LYX_NLS will be set 
> > too. (CMakeLists.txt:190)
> > You can't install with outdated .gmo files.
> > Each time one of the gettext sources changes, the .gmo *may* be outdated.
> 
> Thanks. Let me see whether I understood correctly:
> 
> 1. "-DLYX_NLS=ON" is equivalent to disabling "LYX_NLS".
> 2. I can't really disable "LYX_NLS" as long as I have LYX_INSTALL checked.
> 
> Okay, so what happens if I disable "LYX_INSTALL" then?

Why don't you try?

> Daniel

Kornel

signature.asc
Description: This is a digitally signed message part.

Ticket #10304 : Instant Preview: Too much horizontal space

[Jean-Marc Lasgouttes]

I need some comments on the following  ticket:
http://www.lyx.org/trac/ticket/10304
Producing a patch would not be difficult, but I wonder whether there are 
reasons for this extra spacing that I could have missed.


The situation is that there is a TEXT_TO_INSETOFFSET gap around the 
inset (4 pixels on the 4 sides), plus an extra pixel on the left. I am 
not sure why this is required actually. I guess that the intent is to 
have a preview which has a size approaching the inner text if this text 
is normal text.


The one pixel on the left is the same for all previewed insets, and has 
probable been copied from the math inset (it is present in IPA inset 
too). I guess the intent is to help setting cursor just in front of the 
inset, but it cannot work since the cursor will always go inside it 
anyway. Or it is to display the blinking cursor before the inset and not 
inside it. That makes sense.


I am not sure though that the extra 8 pixels makes sense, and I would be 
willing to remove them. I have reservations too about the extra spacing 
above and below the inset, but removing it would require similar changes 
in Text insets, which is much more work.


I'd be interested to have input at this point.

JMarc

Re: Compiling with Microsoft Visual C++

[racoon]

On 21.07.2016 08:51, Kornel Benko wrote:

Am Donnerstag, 21. Juli 2016 um 08:23:51, schrieb racoon 

On 20.07.2016 14:02, Kornel Benko wrote:

Am Mittwoch, 20. Juli 2016 um 11:26:47, schrieb racoon 

Each time I build a number of .gmo-files, like ar.gmo, are generated
which takes some time.

Maybe they are build again because there was a warning before?

CUSTOMBUILD : cygwin warning :
  MS-DOS style path detected: C:/LyX/LyX2.3.0-build/po/ar.po
Preferred POSIX equivalent is: /cygdrive/c/LyX/LyX2.3.0-build/po/ar.po
CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

I can turn of the warning using the environment variable but that just
gets rid of the messages not the generating process.

Does someone know what that is and whether I can do something about it?

Daniel


You use '-DLYX_NLS=ON', this is the default.

*.po: Text files containing ui-translations (e.g. 'de.po' for German)
*.gmo: the associated compiled files interpreted later by lyx.


Thanks. Not sure I understood though.

I disabled "LYX_NLS" in CMake (could not find any flags containing
"DLYX"). But when compiling the .gmo files are still generated. So the
flag seems to have no effect on this.


This is because you use the cmake-GUI.
From the command line your cmake call should contain '-DLYX_NLS=OFF'.

The gmo-files are created (respectively copied from source if you don't have 
gettext executables)
in the subdirectory po. But with NLS disabled, this directory will newer be 
entered. See CMakeLists.txt:713

But stop ... I see, that if you set LYX_INSTALL, then LYX_NLS will be set too. 
(CMakeLists.txt:190)
You can't install with outdated .gmo files.
Each time one of the gettext sources changes, the .gmo *may* be outdated.


Thanks. Let me see whether I understood correctly:

1. "-DLYX_NLS=ON" is equivalent to disabling "LYX_NLS".
2. I can't really disable "LYX_NLS" as long as I have LYX_INSTALL checked.

Okay, so what happens if I disable "LYX_INSTALL" then?

Daniel

Re: Compiling with Microsoft Visual C++

[Kornel Benko]

Am Donnerstag, 21. Juli 2016 um 08:23:51, schrieb racoon 
> On 20.07.2016 14:02, Kornel Benko wrote:
> > Am Mittwoch, 20. Juli 2016 um 11:26:47, schrieb racoon 
> >> Each time I build a number of .gmo-files, like ar.gmo, are generated
> >> which takes some time.
> >>
> >> Maybe they are build again because there was a warning before?
> >>
> >> CUSTOMBUILD : cygwin warning :
> >>   MS-DOS style path detected: C:/LyX/LyX2.3.0-build/po/ar.po
> >> Preferred POSIX equivalent is: /cygdrive/c/LyX/LyX2.3.0-build/po/ar.po
> >> CYGWIN environment variable option "nodosfilewarning" turns off this
> >> warning.
> >> Consult the user's guide for more details about POSIX paths:
> >> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> >>
> >> I can turn of the warning using the environment variable but that just
> >> gets rid of the messages not the generating process.
> >>
> >> Does someone know what that is and whether I can do something about it?
> >>
> >> Daniel
> >
> > You use '-DLYX_NLS=ON', this is the default.
> >
> > *.po: Text files containing ui-translations (e.g. 'de.po' for German)
> > *.gmo: the associated compiled files interpreted later by lyx.
> 
> Thanks. Not sure I understood though.
> 
> I disabled "LYX_NLS" in CMake (could not find any flags containing 
> "DLYX"). But when compiling the .gmo files are still generated. So the 
> flag seems to have no effect on this.

This is because you use the cmake-GUI.
From the command line your cmake call should contain '-DLYX_NLS=OFF'.

The gmo-files are created (respectively copied from source if you don't have 
gettext executables)
in the subdirectory po. But with NLS disabled, this directory will newer be 
entered. See CMakeLists.txt:713

But stop ... I see, that if you set LYX_INSTALL, then LYX_NLS will be set too. 
(CMakeLists.txt:190)
You can't install with outdated .gmo files.
Each time one of the gettext sources changes, the .gmo *may* be outdated.

> Daniel

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Compiling with Microsoft Visual C++

[racoon]

On 20.07.2016 14:02, Kornel Benko wrote:

Am Mittwoch, 20. Juli 2016 um 11:26:47, schrieb racoon 

Each time I build a number of .gmo-files, like ar.gmo, are generated
which takes some time.

Maybe they are build again because there was a warning before?

CUSTOMBUILD : cygwin warning :
  MS-DOS style path detected: C:/LyX/LyX2.3.0-build/po/ar.po
Preferred POSIX equivalent is: /cygdrive/c/LyX/LyX2.3.0-build/po/ar.po
CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

I can turn of the warning using the environment variable but that just
gets rid of the messages not the generating process.

Does someone know what that is and whether I can do something about it?

Daniel


You use '-DLYX_NLS=ON', this is the default.

*.po: Text files containing ui-translations (e.g. 'de.po' for German)
*.gmo: the associated compiled files interpreted later by lyx.


Thanks. Not sure I understood though.

I disabled "LYX_NLS" in CMake (could not find any flags containing 
"DLYX"). But when compiling the .gmo files are still generated. So the 
flag seems to have no effect on this.


Daniel

Re: Enumitem Updates for Master

[Guenter Milde]

Dear Docutils developers,

On 2016-07-15, Richard Heck wrote:

> I propose to add a couple new styles to the enumitem module in master,
> moslty to give users more of a sense for what it can do. 

I am against adding styles that are not widely used in the enumitem module -
this clutters the style drop-down list whenever enumitem is wanted.

> We could potentially also add another module, Extra Lists, or
> something, that added even more.

Please do this *instead of* and not *in addition to* adding your favourite
list styles to enumitem.module.

Actually, when writing enumitem.module, I put list styles I frequently
use in a local extension "gm-liste.module" which adds Enumerat-alpha and
more compact¹ versions of the standard list styles.

Günter


¹ using less vertical space

Re: Ticket #10304 : Instant Preview: Too much horizontal space

[Scott Kostyshak]

On Thu, Jul 21, 2016 at 04:32:09PM +0200, Jean-Marc Lasgouttes wrote:

> I'd be interested to have input at this point.

No input but I'll be happy to test when you have a patch. It seems like
one of those things that we'll just have to test to see if there are
issues.

Scott


signature.asc
Description: PGP signature

Re: \Omega is not displayed correctly

[Richard Heck]

On 07/21/2016 04:16 PM, Scott Kostyshak wrote:
> On Thu, Jul 21, 2016 at 02:00:15PM -0600, L. Han wrote:
>> After update to 2.2.0, \Omega is not displayed correctly in Lyx. It looks
>> like a bold \neg now. Hope it will be fixed soon. Thanks!
> Hi Han, thanks for this report. For reports like this it's always
> helpful if you give your OS.
>
> Also, which LyX version did you use before upgrading to 2.2.0?

I am sure we have seen a very similar bug before. But I can't access
trac right now

Richard

Re: \Omega is not displayed correctly

[Scott Kostyshak]

On Thu, Jul 21, 2016 at 04:29:32PM -0400, Richard Heck wrote:
> On 07/21/2016 04:16 PM, Scott Kostyshak wrote:
> > On Thu, Jul 21, 2016 at 02:00:15PM -0600, L. Han wrote:
> >> After update to 2.2.0, \Omega is not displayed correctly in Lyx. It looks
> >> like a bold \neg now. Hope it will be fixed soon. Thanks!
> > Hi Han, thanks for this report. For reports like this it's always
> > helpful if you give your OS.
> >
> > Also, which LyX version did you use before upgrading to 2.2.0?
> 
> I am sure we have seen a very similar bug before.

I remember this also. I think we've tried a couple of different
workarounds. If I remember correctly, Mac was the main OS affected.

> But I can't access
> trac right now

Same here. Strangely we do not have any commit messages with "omega"
(except an old one), so perhaps the issue is more general than I
remember.

Scott


signature.asc
Description: PGP signature

Instant previews only repainted if window active or mouse over

[Scott Kostyshak]

This is a minor issue and I'm not even sure how it's supposed to be,
but instant previews are not painted (what I mean specifically is that
after instant previews are generated, their previews are not shown in
LyX) unless the LyX window is active or the mouse is over the LyX
window.

I've never realized this before and just realized it now when doing a
side-by-side comparison of LyX versions while testing JMarc's recent
patch.

My guess is that it has been like this forever, and it makes sense
because usually it doesn't make sense to repaint in LyX unless the LyX
winddow is active (otherwise what would even cause the need to repaint)?

The reason why I found this mildly annoying is that I thought the LyX
preview was just taking a really long time to generate.

To reproduce, enable instant preview for math, open the LyX math manual
on the right side of the screen and a separate window (e.g. terminal) on
the left side. Then scroll to a part where there is math. Zoom out and
immediately click on the other window (the one that is not LyX, e.g.
terminal). The new preview does not show in LyX until you move your
mouse back over the LyX window.

Again, very minor and not sure if worth fixing.

Scott


signature.asc
Description: PGP signature

Re: Ticket #10304 : Instant Preview: Too much horizontal space

[Jean-Marc Lasgouttes]

Le 22/07/2016 à 00:15, Andrew Parsloe a écrit :

I can't check on trac at the moment, but I think the extra space
referred to is that introduced, perhaps a couple of years ago, as a
safety measure so that empty previews would be visible. I think Richard
did the work. (The space annoys me, but an empty preview *is* visible.)


This code was present at the introduction of the preview inset.

JMarc