Re: [patch] Re: \textvisiblespace
On 2011-07-25, Uwe Stöhr wrote: Am 23.07.2011 23:23, schrieb Guenter Milde: What is the replacement character used by Windows? a square An open square or a filled black one? IMV, an open square is not worse than \leer in ERT: both need explanation. It is an open square. This would be worse because this character is used for _every_ character that is unknown by the font. Looking at LyX's special character dialog you get a square by almost half of the characters there. However, in the math guide it would be just one. But I agree that this is rather fragile. Just curious: Did you test whether installing DejaVu (even without using it as Screen Font) helps also on Windows? (I can't do it because I don't have access to a Windows machine.) This doesn't help. You can install as many fonts to Windows as you want, but the default will still by Times New Roman and Arial. So one has to use the dejavu fonts explicitly as screen fonts in the LyX preferences. Here on my Linux box, when I use Times New Roman explicitely as screen font, characters missing in Times New Roman are replaced with characters from another font that has them. Maybe this works only because I use DejaVu Sans as system font. When I do this, I get e.g. \textvisiblespace correctly displayed in LyX's main window but in the menu Insert-Special Character-Symbols I still see a square for \textvisiblespace. So the font LyX uses for the dialog must be changed too, but how can this be done? Jürgen? I suppose that the Menu uses the system-wide default. So you would need to configure the Windows default font. Günter
Re: [patch] Re: \textvisiblespace
On 2011-07-25, Uwe Stöhr wrote: > Am 23.07.2011 23:23, schrieb Guenter Milde: What is the replacement character used by Windows? >>> a square >> An open square or a filled black one? IMV, an open square is not worse than >> "\leer" in ERT: both need explanation. > It is an open square. This would be worse because this character is > used for _every_ character that is unknown by the font. Looking at > LyX's special character dialog you get a square by almost half of the > characters there. However, in the math guide it would be just one. But I agree that this is rather fragile. >> Just curious: Did you test whether installing DejaVu (even without using >> it as Screen Font) helps also on Windows? (I can't do it because I don't >> have access to a Windows machine.) > This doesn't help. You can install as many fonts to Windows as you > want, but the default will still by Times New Roman and Arial. So one > has to use the dejavu fonts explicitly as screen fonts in the LyX > preferences. Here on my Linux box, when I use Times New Roman explicitely as screen font, characters missing in Times New Roman are replaced with characters from another font that has them. Maybe this works only because I use DejaVu Sans as system font. > When I do this, I get e.g. \textvisiblespace correctly > displayed in LyX's main window but in the menu Insert->Special > Character->Symbols I still see a square for \textvisiblespace. So the > font LyX uses for the dialog must be changed too, but how can this be > done? Jürgen? I suppose that the Menu uses the system-wide default. So you would need to configure the Windows default font. Günter
Re: [patch] Re: \textvisiblespace
Am 23.07.2011 23:23, schrieb Guenter Milde: What is the replacement character used by Windows? a square An open square or a filled black one? IMV, an open square is not worse than \leer in ERT: both need explanation. It is an open square. This would be worse because this character is used for _every_ character that is unknown by the font. Looking at LyX's special character dialog you get a square by almost half of the characters there. Just curious: Did you test whether installing DejaVu (even without using it as Screen Font) helps also on Windows? (I can't do it because I don't have access to a Windows machine.) This doesn't help. You can install as many fonts to Windows as you want, but the default will still by Times New Roman and Arial. So one has to use the dejavu fonts explicitly as screen fonts in the LyX preferences. When I do this, I get e.g. \textvisiblespace correctly displayed in LyX's main window but in the menu Insert-Special Character-Symbols I still see a square for \textvisiblespace. So the font LyX uses for the dialog must be changed too, but how can this be done? Jürgen? regards Uwe
Re: [patch] Re: \textvisiblespace
Am 23.07.2011 23:23, schrieb Guenter Milde: What is the replacement character used by Windows? a square An open square or a filled black one? IMV, an open square is not worse than "\leer" in ERT: both need explanation. It is an open square. This would be worse because this character is used for _every_ character that is unknown by the font. Looking at LyX's special character dialog you get a square by almost half of the characters there. Just curious: Did you test whether installing DejaVu (even without using it as Screen Font) helps also on Windows? (I can't do it because I don't have access to a Windows machine.) This doesn't help. You can install as many fonts to Windows as you want, but the default will still by Times New Roman and Arial. So one has to use the dejavu fonts explicitly as screen fonts in the LyX preferences. When I do this, I get e.g. \textvisiblespace correctly displayed in LyX's main window but in the menu Insert->Special Character->Symbols I still see a square for \textvisiblespace. So the font LyX uses for the dialog must be changed too, but how can this be done? Jürgen? regards Uwe
Re: [patch] Re: \textvisiblespace
On 2011-07-22, Uwe Stöhr wrote: Am 22.07.2011 23:52, schrieb Guenter Milde: What is the replacement character used by Windows? a square An open square or a filled black one? IMV, an open square is not worse than \leer in ERT: both need explanation. If we use it in our manuals, then many people will be just unable to view the manual! What does unable to view the manual precisely mean? I meant view it within LyX. As the Windows standard fonts cannot display the character, you will see a square instead within LyX. This might cause confusions because in the PDF output it is correct. However, as the PDF output is better/different in many ways, the confusion is rather limited. Yes, that is why I'm using TeX code in the manual (e.g. the Math manual). If the QT-auto-replacement I see on my system works everywhere, maybe suggesting to install DejaVu with the Windows-Installer might be a more generic solution (for many many more missing Unicode characters)? Good point, I'll put it on my todo list. Just curious: Did you test whether installing DejaVu (even without using it as Screen Font) helps also on Windows? (I can't do it because I don't have access to a Windows machine.) Günter
Re: [patch] Re: \textvisiblespace
On 2011-07-22, Uwe Stöhr wrote: > Am 22.07.2011 23:52, schrieb Guenter Milde: >> What is the replacement character used by Windows? > a square An open square or a filled black one? IMV, an open square is not worse than "\leer" in ERT: both need explanation. If we use it in our manuals, then many people will be just unable to view the manual! >> What does "unable to view the manual" precisely mean? > I meant view it within LyX. As the Windows standard fonts cannot > display the character, you will see a square instead within LyX. This > might cause confusions because in the PDF output it is correct. However, as the PDF output is better/different in many ways, the confusion is rather limited. >>> Yes, that is why I'm using TeX code in the manual (e.g. the Math manual). >> If the "QT-auto-replacement" I see on my system works everywhere, maybe >> suggesting to install DejaVu with the Windows-Installer might be a more >> generic solution (for many many more missing Unicode characters)? > Good point, I'll put it on my todo list. Just curious: Did you test whether installing DejaVu (even without using it as Screen Font) helps also on Windows? (I can't do it because I don't have access to a Windows machine.) Günter
Re: [patch] Re: \textvisiblespace
On 2011-07-15, Uwe Stöhr wrote: The problem is the same under any OS. Our user are free to pick the font they want (with or without accents if they are English speakers, limited to latin1++ for western countries...) and nobody knows whether visible space is in there. No, under my OS (Debian Linux), even if I pick a screen font without the OPEN BOX character, I always see it: QT will use a replacement from another system font that has it. I wonder whether this is Linux specific or maybe even work with QT-apps under Windows if the user installs e.g. the free DejaVu fonts. Could someone with a Windows machine please test? What is the replacement character used by Windows? If we use it in our manuals, then many people will be just unable to view the manual! What does unable to view the manual precisely mean? Are people with an ASCII-only screen font unable to view the German manual with all its äöü? Yes, that is why I'm using TeX code in the manual (e.g. the Math manual). If the QT-auto-replacement I see on my system works everywhere, maybe suggesting to install DejaVu with the Windows-Installer might be a more generic solution (for many many more missing Unicode characters)? Günter
Re: [patch] Re: \textvisiblespace
Am 22.07.2011 23:52, schrieb Guenter Milde: What is the replacement character used by Windows? a square If we use it in our manuals, then many people will be just unable to view the manual! What does unable to view the manual precisely mean? I meant view it within LyX. As the Windows standard fonts cannot display the character, you will see a square instead within LyX. This might cause confusions because in the PDF output it is correct. Yes, that is why I'm using TeX code in the manual (e.g. the Math manual). If the QT-auto-replacement I see on my system works everywhere, maybe suggesting to install DejaVu with the Windows-Installer might be a more generic solution (for many many more missing Unicode characters)? Good point, I'll put it on my todo list. regards Uwe
Re: [patch] Re: \textvisiblespace
Am 21.07.2011 08:30, schrieb Jürgen Spitzmüller: The implementation in InsetSpace is indeed better for the on-screen representation. So I'm convinced now, but we should do something about the menu logic. Perhaps we can use the menu Insert-Special character-Visible space that inserts an InsetSpace with \textvisiblespace? I'm not sure. The split of Special characters and Special formatting was performed basically because the special characters menu was too crowded. The distinction is not sensible in all cases anyway. I would not populate the special characters menu with a space item. The \textvisiblespace item of InsetSpace will basically serve to make a space visible. If they want the character, people will also find it in the symbols dialog. OK. I'm hereby retract my patch proposal. So Pavel, from my side, please go on with the InsetSpace implementation. At this point I'm not yet convinced. I still think that also in the InsetSpace implementation, it should not be possible to change a visible space to e.g. an interword space because their width in the output will not be the same. This makes no sense to me. Why should I'm not be allowed to do such a change? I'm doing such changes all the time, with good reasons. After all, you are also allowed to change a 10cm hspace to a 1mm hspace, where the width in the output will change even more. Sure, but then the user is aware what the change means. By changing a space to a character, he might not know the consequences. But if you really think that this won't harm, then do it this way. regards Uwe
Re: [patch] Re: \textvisiblespace
On 2011-07-15, Uwe Stöhr wrote: >> The problem is the same under any OS. Our user are free to pick the >> font they want (with or without accents if they are English speakers, >> limited to latin1++ for western countries...) and nobody knows whether >> visible space is in there. No, under my OS (Debian Linux), even if I pick a screen font without the OPEN BOX character, I always see it: QT will use a replacement from another system font that has it. I wonder whether this is Linux specific or maybe even work with QT-apps under Windows if the user installs e.g. the free DejaVu fonts. Could someone with a Windows machine please test? What is the replacement character used by Windows? >> If we use it in our manuals, then many people will be just unable to >> view the manual! What does "unable to view the manual" precisely mean? Are people with an "ASCII-only" screen font unable to view the German manual with all its äöü? > Yes, that is why I'm using TeX code in the manual (e.g. the Math manual). If the "QT-auto-replacement" I see on my system works everywhere, maybe suggesting to install DejaVu with the Windows-Installer might be a more generic solution (for many many more missing Unicode characters)? Günter
Re: [patch] Re: \textvisiblespace
Am 22.07.2011 23:52, schrieb Guenter Milde: What is the replacement character used by Windows? a square If we use it in our manuals, then many people will be just unable to view the manual! What does "unable to view the manual" precisely mean? I meant view it within LyX. As the Windows standard fonts cannot display the character, you will see a square instead within LyX. This might cause confusions because in the PDF output it is correct. Yes, that is why I'm using TeX code in the manual (e.g. the Math manual). If the "QT-auto-replacement" I see on my system works everywhere, maybe suggesting to install DejaVu with the Windows-Installer might be a more generic solution (for many many more missing Unicode characters)? Good point, I'll put it on my todo list. regards Uwe
Re: [patch] Re: \textvisiblespace
Am 21.07.2011 08:30, schrieb Jürgen Spitzmüller: The implementation in InsetSpace is indeed better for the on-screen representation. So I'm convinced now, but we should do something about the menu logic. Perhaps we can use the menu Insert->Special character->Visible space that inserts an InsetSpace with \textvisiblespace? I'm not sure. The split of "Special characters" and "Special formatting" was performed basically because the special characters menu was too crowded. The distinction is not sensible in all cases anyway. I would not populate the special characters menu with a space item. The \textvisiblespace item of InsetSpace will basically serve "to make a space visible". If they want the character, people will also find it in the symbols dialog. OK. I'm hereby retract my patch proposal. So Pavel, from my side, please go on with the InsetSpace implementation. At this point I'm not yet convinced. I still think that also in the InsetSpace implementation, it should not be possible to change a visible space to e.g. an interword space because their width in the output will not be the same. This makes no sense to me. Why should I'm not be allowed to do such a change? I'm doing such changes all the time, with good reasons. After all, you are also allowed to change a 10cm hspace to a 1mm hspace, where the width in the output will change even more. Sure, but then the user is aware what the change means. By changing a space to a character, he might not know the consequences. But if you really think that this won't harm, then do it this way. regards Uwe
Re: [patch] Re: \textvisiblespace
Uwe Stöhr wrote:
Am 20.07.2011 08:10, schrieb Jürgen Spitzmüller:
It is totally confusing that we have the menu Insert-Special
character
that already provides the char.
I don't understand.
We have the menu
Insert-Special character
for characters but the space inset is in the menu
Insert-Formatting
So the space inset is a formating inset and \textvisiblespace is a character
that you would not expect in the Formattings menu.
Moreover \textvisiblespace is already available in the menu
Insert-Special character
via Symbols...
Sure. As I said, having both approaches is completely fine. That's what I'm
proposing. Both serve different uses.
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.
Sure. InsetSpace _is_ in that menu.
No it is in Formatting not in Special character.
That's what I said. Special formatting menu.
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.
Of course I can scale a space. Compare foo~bar to foo{\huge ~}bar
I can also emphasize it. The difference is more subtle, but it's there.
OK, and with my solution one would also not see within LyX when it is e.g.
painted red. Will this be visible in the InsetSpace implementation?
Sure. If we take the right color definition.
Then we have the brace, the arrows, the line and all in InsetSpace
(hfill). These I can even paint red.
The implementation in InsetSpace is indeed better for the on-screen
representation. So I'm convinced now, but we should do something about the
menu logic. Perhaps we can use the menu Insert-Special character-Visible
space that inserts an InsetSpace with \textvisiblespace?
I'm not sure. The split of Special characters and Special formatting was
performed basically because the special characters menu was too crowded. The
distinction is not sensible in all cases anyway. I would not populate the
special characters menu with a space item. The \textvisiblespace item of
InsetSpace will basically serve to make a space visible. If they want the
character, people will also find it in the symbols dialog.
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.
No. See above.
At this point I'm not yet convinced. I still think that also in the
InsetSpace implementation, it should not be possible to change a visible
space to e.g. an interword space because their width in the output will not
be the same.
This makes no sense to me. Why should I'm not be allowed to do such a change?
I'm doing such changes all the time, with good reasons. After all, you are
also allowed to change a 10cm hspace to a 1mm hspace, where the width in the
output will change even more.
Jürgen
regards Uwe
Re: [patch] Re: \textvisiblespace
Uwe Stöhr wrote:
> Am 20.07.2011 08:10, schrieb Jürgen Spitzmüller:
> >>It is totally confusing that we have the menu Insert->Special
> >>character
> >>
> >> that already provides the char.
> >
> > I don't understand.
>
> We have the menu
> Insert->Special character
> for characters but the space inset is in the menu
> Insert->Formatting
> So the space inset is a formating inset and \textvisiblespace is a character
> that you would not expect in the Formattings menu.
> Moreover \textvisiblespace is already available in the menu
> Insert->Special character
> via Symbols...
Sure. As I said, having both approaches is completely fine. That's what I'm
proposing. Both serve different uses.
> >> 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.
> >
> > Sure. InsetSpace _is_ in that menu.
>
> No it is in Formatting not in Special character.
That's what I said. Special formatting menu.
> >> 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.
> >
> > Of course I can scale a space. Compare "foo~bar" to "foo{\huge ~}bar"
> > I can also emphasize it. The difference is more subtle, but it's there.
>
> OK, and with my solution one would also not see within LyX when it is e.g.
> painted red. Will this be visible in the InsetSpace implementation?
Sure. If we take the right color definition.
> > Then we have the brace, the arrows, the line and all in InsetSpace
> > (hfill). These I can even paint red.
>
> The implementation in InsetSpace is indeed better for the on-screen
> representation. So I'm convinced now, but we should do something about the
> menu logic. Perhaps we can use the menu Insert->Special character->Visible
> space that inserts an InsetSpace with \textvisiblespace?
I'm not sure. The split of "Special characters" and "Special formatting" was
performed basically because the special characters menu was too crowded. The
distinction is not sensible in all cases anyway. I would not populate the
special characters menu with a space item. The \textvisiblespace item of
InsetSpace will basically serve "to make a space visible". If they want the
character, people will also find it in the symbols dialog.
> >> 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.
> >
> > No. See above.
>
> At this point I'm not yet convinced. I still think that also in the
> InsetSpace implementation, it should not be possible to change a visible
> space to e.g. an interword space because their width in the output will not
> be the same.
This makes no sense to me. Why should I'm not be allowed to do such a change?
I'm doing such changes all the time, with good reasons. After all, you are
also allowed to change a 10cm hspace to a 1mm hspace, where the width in the
output will change even more.
Jürgen
> regards Uwe
Re: [patch] Re: \textvisiblespace
Uwe Stöhr wrote:
It is totally confusing that we have the menu Insert-Special character
that already provides the char.
I don't understand.
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.
Sure. InsetSpace _is_ in that menu.
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.
Of course I can scale a space. Compare foo~bar to foo{\huge ~}bar
I can also emphasize it. The difference is more subtle, but it's there.
Then we have the brace, the arrows, the line and all in InsetSpace (hfill).
These I can even paint red.
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 what if I do not want to have a listing, but a visible space in text?
Listing is a special case.
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.
No. See above.
Jürgen
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
regards Uwe
Re: [patch] Re: \textvisiblespace
Am 20.07.2011 08:10, schrieb Jürgen Spitzmüller:
It is totally confusing that we have the menu Insert-Special character
that already provides the char.
I don't understand.
We have the menu
Insert-Special character
for characters but the space inset is in the menu
Insert-Formatting
So the space inset is a formating inset and \textvisiblespace is a character that you would not
expect in the Formattings menu.
Moreover \textvisiblespace is already available in the menu
Insert-Special character
via Symbols...
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.
Sure. InsetSpace _is_ in that menu.
No it is in Formatting not in Special character.
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.
Of course I can scale a space. Compare foo~bar to foo{\huge ~}bar
I can also emphasize it. The difference is more subtle, but it's there.
OK, and with my solution one would also not see within LyX when it is e.g. painted red. Will this be
visible in the InsetSpace implementation?
Then we have the brace, the arrows, the line and all in InsetSpace (hfill).
These I can even paint red.
The implementation in InsetSpace is indeed better for the on-screen representation. So I'm convinced
now, but we should do something about the menu logic. Perhaps we can use the menu Insert-Special
character-Visible space that inserts an InsetSpace with \textvisiblespace?
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.
No. See above.
At this point I'm not yet convinced. I still think that also in the InsetSpace implementation, it
should not be possible to change a visible space to e.g. an interword space because their width in
the output will not be the same.
regards Uwe
Re: [patch] Re: \textvisiblespace
Uwe Stöhr wrote:
> It is totally confusing that we have the menu Insert->Special character
> that already provides the char.
I don't understand.
> 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.
Sure. InsetSpace _is_ in that menu.
> 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.
Of course I can scale a space. Compare "foo~bar" to "foo{\huge ~}bar"
I can also emphasize it. The difference is more subtle, but it's there.
Then we have the brace, the arrows, the line and all in InsetSpace (hfill).
These I can even paint red.
> > 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 what if I do not want to have a listing, but a visible space in text?
Listing is a special case.
> 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.
No. See above.
Jürgen
> > 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
>
> regards Uwe
Re: [patch] Re: \textvisiblespace
Am 20.07.2011 08:10, schrieb Jürgen Spitzmüller:
It is totally confusing that we have the menu Insert->Special character
that already provides the char.
I don't understand.
We have the menu
Insert->Special character
for characters but the space inset is in the menu
Insert->Formatting
So the space inset is a formating inset and \textvisiblespace is a character that you would not
expect in the Formattings menu.
Moreover \textvisiblespace is already available in the menu
Insert->Special character
via Symbols...
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.
Sure. InsetSpace _is_ in that menu.
No it is in Formatting not in Special character.
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.
Of course I can scale a space. Compare "foo~bar" to "foo{\huge ~}bar"
I can also emphasize it. The difference is more subtle, but it's there.
OK, and with my solution one would also not see within LyX when it is e.g. painted red. Will this be
visible in the InsetSpace implementation?
Then we have the brace, the arrows, the line and all in InsetSpace (hfill).
These I can even paint red.
The implementation in InsetSpace is indeed better for the on-screen representation. So I'm convinced
now, but we should do something about the menu logic. Perhaps we can use the menu Insert->Special
character->Visible space that inserts an InsetSpace with \textvisiblespace?
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.
No. See above.
At this point I'm not yet convinced. I still think that also in the InsetSpace implementation, it
should not be possible to change a visible space to e.g. an interword space because their width in
the output will not be the same.
regards Uwe
Re: [patch] Re: \textvisiblespace
Am 19.07.2011 um 01:05 schrieb Uwe Stöhr:
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.
...
+ 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).
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
Re: [patch] Re: \textvisiblespace
Uwe Stöhr wrote: 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. 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
Re: [patch] Re: \textvisiblespace
Jean-Marc Lasgouttes wrote: 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. + 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?) 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
Re: [patch] Re: \textvisiblespace
Jürgen Spitzmüller wrote: 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
Re: [patch] Re: \textvisiblespace
Pavel Sanda wrote: 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 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
Re: [patch] Re: \textvisiblespace
Le 19/07/2011 08:41, Jürgen Spitzmüller a écrit : That's not true for all spaces. Non-break spaces are of fixed width as well. And so is \thinspace. [...] 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
Re: [patch] Re: \textvisiblespace
Am 19.07.2011 08:14, schrieb 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
Re: [patch] Re: \textvisiblespace
Am 19.07.2011 08:41, schrieb 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. 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. 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 regards Uwe
Re: [patch] Re: \textvisiblespace
Jürgen Spitzmüller wrote: Pavel Sanda wrote: 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 is to both integrate it to InsetSpace yes that means your vote goes to 2 and to support it via unicodesymbols (if not already the case). thats already the case and the way i'm using it in 1.6. its actually part of solution 1 and it is a pity this symbol is not properly rendered with windows fonts. the patch would be uninvasive, backportable to 2.0 and with correct change track rendering. 2,3 are slightly worse as far CT is concerned but both can work (3 needs that the color is changed to standard font color as JMarc pointed out, but thats trivial). pavel
Re: [patch] Re: \textvisiblespace
Am 19.07.2011 um 01:05 schrieb Uwe Stöhr:
> 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.
...
>> + 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).
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
Re: [patch] Re: \textvisiblespace
Uwe Stöhr wrote:
> > 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.
> 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
Re: [patch] Re: \textvisiblespace
Jean-Marc Lasgouttes wrote: >> 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. > + 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?) 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
Re: [patch] Re: \textvisiblespace
Jürgen Spitzmüller wrote:
> 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
Re: [patch] Re: \textvisiblespace
Pavel Sanda wrote: > 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 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
Re: [patch] Re: \textvisiblespace
Le 19/07/2011 08:41, Jürgen Spitzmüller a écrit :
That's not true for all spaces. Non-break spaces are of fixed width as well.
And so is \thinspace.
[...]
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
Re: [patch] Re: \textvisiblespace
Am 19.07.2011 08:14, schrieb 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
Re: [patch] Re: \textvisiblespace
Am 19.07.2011 08:41, schrieb 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.
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.
> 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
regards Uwe
Re: [patch] Re: \textvisiblespace
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > 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 is to both integrate it to InsetSpace yes that means your vote goes to 2 >and to support it via unicodesymbols (if not already the case). thats already the case and the way i'm using it in 1.6. its actually part of solution 1 and it is a pity this symbol is not properly rendered with windows fonts. the patch would be uninvasive, backportable to 2.0 and with correct change track rendering. 2,3 are slightly worse as far CT is concerned but both can work (3 needs that the color is changed to standard font color as JMarc pointed out, but thats trivial). pavel
Re: [patch] Re: \textvisiblespace
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???).
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
Re: [patch] Re: \textvisiblespace
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
Re: [patch] Re: \textvisiblespace
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"???).
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
Re: [patch] Re: \textvisiblespace
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
