Am 19.07.2011 00:05, schrieb Jean-Marc Lasgouttes:
Le 15/07/11 22:30, Uwe Stöhr a écrit :
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.))
Remarks on the patch:
+ case VISIBLE_SPACE:
+ s = "x";
+ break;
Please use the width of ' ', as we do for protected space.
OK.
+ 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.
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.
+ 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).
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.
+ 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?)
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
