[patch] Re: \textvisiblespace

[Jean-Marc Lasgouttes]

I don't agree that implementing it as part of the space inset is a good
idea. \textvisiblespace is not a space in the sense of the meaning but a
special character. It does not create a space, but a character. I would
therefore like to implement this as special character like an ellipsis.

I still think it is wrong, but I am not going to fight forever on that
(what is there a space in "foo bar" and not "foo_bar"???).

Attached is a patch that does this.
The advantage is that we avoid confusions. If we would implement it as
InsetSpace, it is hard for the user to distinguish it within LyX from
the other spaces.

Just output it in black instead of blue.

Remarks on the patch:

+ case VISIBLE_SPACE:
+ s = "x";
+ break;

Please use the width of ' ', as we do for protected space.

+ case VISIBLE_SPACE:
+ {
+ frontend::FontMetrics const & fm =
+ theFontMetrics(font);
+
+ // An "u" the width of an 'x' and the third height of a 'W'
+ int wid = fm.width(char_type('x'));
+ int oxwid = x;
+ int hei = fm.ascent(char_type('W'));
+ int xp[4], yp[4];
+
+ xp[0] = oxwid; yp[0] = y - hei/3;
+ xp[1] = oxwid; yp[1] = y;
+ xp[2] = oxwid + wid; yp[2] = y;
+ xp[3] = oxwid + wid; yp[3] = y - hei/3;
+
+ pi.pain.lines(xp, yp, 4, Color_special);
+ break;

Please use the same code as for protected space. There is no reason to
use a different drawing ("the third height of a 'W'" seems especially
esoteric to me). I also think color should be black.

+ case VISIBLE_SPACE:
+ os << "\\textvisiblespace{}";
+ break;

For LaTeX output, can't we just output the unicode character and let our
stream sort out the right output? We may want unicode to output natively
(maybe also for other special characters, actually).

+ case VISIBLE_SPACE:
+ os << "|_|";
+ return 3;

I do not think it makes much sense to use this ascii-art output here. I
would use a plain space or an underscore. Or even the unicode character,
since we output to utf8 (Hmmm, do we?)

+ case VISIBLE_SPACE:
+ os << "|_|";
+ break;

ditto.

bool InsetSpecialChar::isLetter() const
{
return kind_ == HYPHENATION || kind_ == LIGATURE_BREAK
- || kind_ == NOBREAKDASH;
+ || kind_ == NOBREAKDASH || kind_ == VISIBLE_SPACE;
}

This means that "foo_bar" will be only one word. Is it really what you
intend?

JMarc

[Uwe Stöhr]

I don't agree that implementing it as part of the space inset is a good
idea. \textvisiblespace is not a space in the sense of the meaning but a
special character. It does not create a space, but a character. I would
therefore like to implement this as special character like an ellipsis.

I still think it is wrong, but I am not going to fight forever on that (what is there a space in
"foo bar" and not "foo_bar"???).

The internal behaviour of a space and a character is different. LaTeX can change the width of spaces
to e.g. fit a line into the column margins. Spaces are something completely different than
characters. \textvisiblespace is nothing more than a character built out of 3 strokes. Many fonts
not even have a real glyph for it. This character only represents a space, but technically it is
nothing else like any other character. So you could also simply use "_" to visualize a space in e.g.
a code. And I think you agree that you wouldn't add the "_" character to the space inset. That is
why I think that it does not belong to the space inset but to the special character.

What we can implement btw. is \baselineskip:
\hspace{\baselineskip}
this is needed often.

(Another thing is the usability. As said it is confusing that I would be able to change a space to a
character and vice versa when it would be implemented as space inset. And how should we visualise
it? We already have red "|_|" for negative spaces but also for a protected space and dark blue for
an interword space. Adding a new black one would be confusing and the user will probably not notice
this difference when they change it. (Think about the color blind and elder people.))

+ s = "x";
+ break;
Please use the width of ' ', as we do for protected space.

OK.

+ {
+ frontend::FontMetrics const & fm =
+ theFontMetrics(font);
+
+ // An "u" the width of an 'x' and the third height of a 'W'
+ int wid = fm.width(char_type('x'));
+ int oxwid = x;
+ int hei = fm.ascent(char_type('W'));
+ int xp[4], yp[4];
+
+ xp[0] = oxwid; yp[0] = y - hei/3;
+ xp[1] = oxwid; yp[1] = y;
+ xp[2] = oxwid + wid; yp[2] = y;
+ xp[3] = oxwid + wid; yp[3] = y - hei/3;
+
+ pi.pain.lines(xp, yp, 4, Color_special);
+ break;
Please use the same code as for protected space. There is no reason to use a different drawing ("the
third height of a 'W'" seems especially esoteric to me). I also think color should be black.

My intention was to do the same as for the menu separator to distinguish it from spaces in the space
inset. I therefore used its code and color. The one third is intended - I measured the height on
screen with zooming into the PDF output and it is one third for the standard font. Every font looks
different, for example, with Latin Modern it is not like an "u", but like a sag. So we have to find
a compromise and I thought is a good idea to imitate the standard font Computer Modern. But in fact
is it really that important - we are not WYSIWYG? I think it is more important that the user don't
mix the character with the real spaces.

OK, I can also use the metrics of the protected space, but it is no space but a character ;-). But
just tell what you prefer and I'll use this.

+ os << "\\textvisiblespace{}";
+ break;
For LaTeX output, can't we just output the unicode character and let our stream sort out the right
output? We may want unicode to output natively (maybe also for other special characters, actually).

I can do this, but what is the benefit? I know users looking at the LyX file directly with a text
editor, and on Windows they would only see a square.

+ os << "|_|";
+ return 3;
I do not think it makes much sense to use this ascii-art output here. I would use a plain space or
an underscore. Or even the unicode character, since we output to utf8 (Hmmm, do we?)

The problem is that when you use the Unicode character and the user open the result e.g. in Windows
standard editor "Notepad" he sees a black square instead because the Windows standard fonts (Arial,
times new Roman, etc.) don't have a representation for this character (at least here on my XP).
I also thought about using an underscore but this could lead to confusions. Personally I use
\textvisiblespace for commands, but they sometimes already contain underscores, so it would be
impossible to distinguish them.
I must admit, that I don't have a real clever idea here.

bool InsetSpecialChar::isLetter() const
{
return kind_ == HYPHENATION || kind_ == LIGATURE_BREAK
- || kind_ == NOBREAKDASH;
+ || kind_ == NOBREAKDASH || kind_ == VISIBLE_SPACE;
}
This means that "foo_bar" will be only one word. Is it really what you intend?

You are right, this is not correct and I will remove this.

thanks and regards
Uwe

[Stephan Witt]

I don't agree that implementing it as part of the space inset is a good
idea. \textvisiblespace is not a space in the sense of the meaning but a
special character. It does not create a space, but a character. I would
therefore like to implement this as special character like an ellipsis.

...

+ os << "\\textvisiblespace{}";
+ break;
For LaTeX output, can't we just output the unicode character and let our stream sort out the right
output? We may want unicode to output natively (maybe also for other special characters, actually).

I can do this, but what is the benefit? I know users looking at the LyX file directly with a text editor, and on Windows they would only see a square.

+ os << "|_|";
+ return 3;
I do not think it makes much sense to use this ascii-art output here. I would use a plain space or
an underscore. Or even the unicode character, since we output to utf8 (Hmmm, do we?)

The problem is that when you use the Unicode character and the user open the result e.g. in Windows standard editor "Notepad" he sees a black square instead because the Windows standard fonts (Arial, times new Roman, etc.) don't have a representation for this character (at least here on my XP).

Sorry, I cannot resist... Notepad is not an editor. It's an excuse for not having one.
Every time I have to view a file on stock windows I get an attack of windows hate.
It's the same with the never ending newline story.
One should at least use Wordpad instead.

Stephan

[Uwe Stöhr]

Post by Stephan Witt
Sorry, I cannot resist... Notepad is not an editor. It's an excuse for not having one.
Every time I have to view a file on stock windows I get an attack of windows hate.
It's the same with the never ending newline story.
One should at least use Wordpad instead.

This won't help because it is using the same Windows standard fonts which display \textvisiblespace
as the square that indicates an unknown character.

regards Uwe

[Jürgen Spitzmüller]

Post by Uwe Stöhr

Post by Jean-Marc Lasgouttes
I still think it is wrong, but I am not going to fight forever on that
(what is there a space in "foo bar" and not "foo_bar"???).

The internal behaviour of a space and a character is different. LaTeX can
change the width of spaces to e.g. fit a line into the column margins.

That's not true for all spaces. Non-break spaces are of fixed width as well.
And so is \thinspace.

Post by Uwe Stöhr
Spaces are something completely different than characters.
\textvisiblespace is nothing more than a character built out of 3 strokes.
Many fonts not even have a real glyph for it. This character only
represents a space, but technically it is nothing else like any other
character. So you could also simply use "_" to visualize a space in e.g. a
code.

And this is exactly why it makes sense. It's a possibility to represent a
space. Why shouldn't InsetSpace allow for that possibility?

The discussion about glyph classification ("technical symbol" vs. "space") is
completely irrelevant for most users. They might just want to "make a space
visible", and that's what \textvisible space is useful for.

Jürgen

[Pavel Sanda]

Post by Jürgen Spitzmüller
And this is exactly why it makes sense. It's a possibility to represent a
space. Why shouldn't InsetSpace allow for that possibility?
The discussion about glyph classification ("technical symbol" vs. "space") is
completely irrelevant for most users. They might just want to "make a space
visible", and that's what \textvisible space is useful for.

the border of "technical symbol" vs. "space" is fuzzy to me and i don't
have hard opinion to dicuss it.

but to sum up as the time passed we have 3 patches:
1. special symbol - simple unicode char
2. part of insetspace
3. special symbol - specific drawing

if my counting is right than
1 - Guenter
2 - Juergen, JMarc
3 - Uwe

correct?

my vote can go to any solution which also have change tracking painting
correct. i didn't tested it for all solutions yet (busy atm), but it was
the real cause why i started the whole thread.

don't need space in the code block (we have listings after all - they already
know this) but need to typeset and see colorized(corrected) whitespace typos in
the proofread of book, so CT is the critical point for me.

pavel

[Jürgen Spitzmüller]

Post by Pavel Sanda
the border of "technical symbol" vs. "space" is fuzzy to me and i don't
have hard opinion to dicuss it.
1. special symbol - simple unicode char
2. part of insetspace
3. special symbol - specific drawing
if my counting is right than
1 - Guenter
2 - Juergen, JMarc
3 - Uwe
correct?

My vote is to both integrate it to InsetSpace and to support it via
unicodesymbols (if not already the case). Both approaches have different uses,
and as already pointed out in an earlier mail to this thread, we cover many
glyphs via unicodesymbols that are also available via specific insets or
otherwise (think NO_BREAK_SPACE, think ENDASH, f.ex.).

Jürgen

[Jean-Marc Lasgouttes]

Post by Jürgen Spitzmüller
That's not true for all spaces. Non-break spaces are of fixed width as well.
And so is \thinspace.

[...]

Post by Jürgen Spitzmüller
And this is exactly why it makes sense. It's a possibility to represent a
space. Why shouldn't InsetSpace allow for that possibility?
The discussion about glyph classification ("technical symbol" vs. "space") is
completely irrelevant for most users. They might just want to "make a space
visible", and that's what \textvisible space is useful for.

Even better than AI: Jürgen Spitzmüller! You write my message even
before I have begun to formulate it properly in my head. That's great.

JMarc

[Uwe Stöhr]

Post by Jürgen Spitzmüller
And this is exactly why it makes sense. It's a possibility to represent a
space. Why shouldn't InsetSpace allow for that possibility?

It is totally confusing that we have the menu Insert->Special character that already provides the
char. OK, this doesn't work on windows because the Windows standard fonts don't support to display
this character and one therefore cannot even see it in the special character dialog.
But we also have the menu for special formatting characters and that is what \textvisiblespace is.

Inserting it as a space is illogical. I mean with a character I can really do something, with a
space not. So I can paint it red, I can emphasize it, I can scale and rotate it - all because it is
a character. All this cannot be done with a space. Or do you ant to extend the space insert that it
is possible to apply character styles and font formattings to it.
So yes, the concept of spaces and characters is important here.

Post by Jürgen Spitzmüller
The discussion about glyph classification ("technical symbol" vs. "space") is
completely irrelevant for most users. They might just want to "make a space
visible", and that's what \textvisible space is useful for.

They can already do this in listings and when I want a character to visualize it is logical to me
that I insert an appropriate character for it.
But it is illogical that I can transform a real space to a character with all the consequences in an
inset that is designed for spaced and not characters.

Post by Jürgen Spitzmüller
1. special symbol - simple Unicode char
2. part of insetspace
3. special symbol - specific drawing

regards Uwe

[Pavel Sanda]

Post by Jean-Marc Lasgouttes

Attached is a patch that does this.
The advantage is that we avoid confusions. If we would implement it as
InsetSpace, it is hard for the user to distinguish it within LyX from
the other spaces.

Just output it in black instead of blue.

this is already implemented in my 2nd patch and works fine.

Post by Jean-Marc Lasgouttes
+ os << "|_|";
+ return 3;
I do not think it makes much sense to use this ascii-art output here. I
would use a plain space or an underscore. Or even the unicode character,
since we output to utf8 (Hmmm, do we?)

not tested but iirc i saw some complaint that we dont use utf8 as an
output. anyway we should use just plain ' '. using "|_|" is just crazy
when you understand it can be part of C++ code output ;)

i didnt checked carefully, but isn't this patch missing fileformat bump?
pavel