Talk:2109: Invisible Formatting - Revision history

172.69.43.167: Proper "unsigned"ing.

2024-08-01T11:36:00Z

Proper "unsigned"ing.

172.68.245.24 at 10:06, 1 August 2024

2024-08-01T10:06:14Z

162.158.146.41 at 02:05, 25 August 2022

2022-08-25T02:05:21Z

Aaron of Mpls: added missing newline between comments

2022-08-23T00:49:19Z

added missing newline between comments

172.68.189.193: formatting

2019-07-11T00:18:50Z

formatting

172.68.189.193 at 00:15, 11 July 2019

2019-07-11T00:15:24Z

JohnHawkinson: fix 172.68.144.145 link, ooops

2019-03-04T14:49:15Z

fix 172.68.144.145 link, ooops

JohnHawkinson: Longer explanation for removal of inappopriate claims of Randall's word processing practices and alleged non-familiarity with word processors.

2019-03-04T14:48:12Z

Longer explanation for removal of inappopriate claims of Randall's word processing practices and alleged non-familiarity with word processors.

JohnHawkinson: Belated comment re proportionally spaced width of boldface versus roman

2019-02-23T03:23:20Z

Belated comment re proportionally spaced width of boldface versus roman

Kynde at 10:06, 13 February 2019

2019-02-13T10:06:56Z

@@ Line 52: / Line 52: @@
 In LibreOffice Writer on Linux if I select a word with double-click it doesn't include the space, but if I select it with the keyboard using Ctrl+Shift+RightArrow it '''does''' include the space. In the comic it looks like the selection was made with the mouse, but it's not explicit. [[Special:Contributions/172.68.189.193|172.68.189.193]] 00:15, 11 July 2019 (UTC)
-I do this. (Unsigned)
+I do this. {{unsigned ip|162.158.146.41|02:05, 25 August 2022}}
 I work with some autogenerated documents that are over 90% formatting (by file size), despite being pretty uniform to the eye. Still trying to figure out how to edit the autogenerator to '''not''' do that. [[Special:Contributions/172.68.245.24|172.68.245.24]] 10:06, 1 August 2024 (UTC)

← Older revision		Revision as of 10:06, 1 August 2024
Line 52:		Line 52:
	In LibreOffice Writer on Linux if I select a word with double-click it doesn't include the space, but if I select it with the keyboard using Ctrl+Shift+RightArrow it '''does''' include the space. In the comic it looks like the selection was made with the mouse, but it's not explicit. [[Special:Contributions/172.68.189.193\|172.68.189.193]] 00:15, 11 July 2019 (UTC)		In LibreOffice Writer on Linux if I select a word with double-click it doesn't include the space, but if I select it with the keyboard using Ctrl+Shift+RightArrow it '''does''' include the space. In the comic it looks like the selection was made with the mouse, but it's not explicit. [[Special:Contributions/172.68.189.193\|172.68.189.193]] 00:15, 11 July 2019 (UTC)

−	I do this.	+	I do this. (Unsigned)
		+
		+	I work with some autogenerated documents that are over 90% formatting (by file size), despite being pretty uniform to the eye. Still trying to figure out how to edit the autogenerator to '''not''' do that. [[Special:Contributions/172.68.245.24\|172.68.245.24]] 10:06, 1 August 2024 (UTC)

← Older revision		Revision as of 02:05, 25 August 2022
Line 51:		Line 51:

	In LibreOffice Writer on Linux if I select a word with double-click it doesn't include the space, but if I select it with the keyboard using Ctrl+Shift+RightArrow it '''does''' include the space. In the comic it looks like the selection was made with the mouse, but it's not explicit. [[Special:Contributions/172.68.189.193\|172.68.189.193]] 00:15, 11 July 2019 (UTC)		In LibreOffice Writer on Linux if I select a word with double-click it doesn't include the space, but if I select it with the keyboard using Ctrl+Shift+RightArrow it '''does''' include the space. In the comic it looks like the selection was made with the mouse, but it's not explicit. [[Special:Contributions/172.68.189.193\|172.68.189.193]] 00:15, 11 July 2019 (UTC)
		+
		+	I do this.

@@ Line 4: / Line 4: @@
 :Some programming puzzles are often solved with stuff like this: AΑ [[User:Fabian42|Fabian42]] ([[User talk:Fabian42|talk]]) 15:19, 8 February 2019 (UTC)
 :"l" (lower-case "L") is a valid suffix to integer literals in C and derived languages. It indicates the number is of the "long int" type as opposed to a plain "int". Because C automatically upconverts the "int" type into "long int" when needed, the "l" suffix is rarely used. The result: "long int a = 1;" and "long int a = 1l;" mean exactly the same thing, and both statements are perfectly standard and won't raise any warning from compilers. "ll" (double el) is also a valid suffix, this time for the "long long int" type. [[User:GuB|GuB]] ([[User talk:GuB|talk]]) 15:39, 8 February 2019 (UTC)
-:Typing lowercase ''L'' instead of ''1'' is a common thing for people of a certain age.  Old manual typewriters usually don't have a "1" key, so people learned to use lowercase ''L'' instead -- and sometimes slip back into that habit on newer technology. --[[User:Aaron of Mpls|Aaron of Mpls]] ([[User talk:Aaron of Mpls|talk]]) 02:03, 9 February 2019 (UTC) Tha's exactly what happened in my example. I blame the programmer, though, for allowing a letter where a numeral was required or possibly converting the l to a 1 if the programmer knew such a thing ever happened. In either case, it shouldn't have allowed the l to just sit there like a bomb waiting to blow apart the post-tax-year processing. [[Special:Contributions/172.68.58.83|172.68.58.83]] 15:22, 9 February 2019 (UTC)
+:Typing lowercase ''L'' instead of ''1'' is a common thing for people of a certain age.  Old manual typewriters usually don't have a "1" key, so people learned to use lowercase ''L'' instead -- and sometimes slip back into that habit on newer technology. --[[User:Aaron of Mpls|Aaron of Mpls]] ([[User talk:Aaron of Mpls|talk]]) 02:03, 9 February 2019 (UTC)
 I went to this page, expecting it to be self-referential. Was not disappointed. [[User:Fabian42|Fabian42]] ([[User talk:Fabian42|talk]]) 15:19, 8 February 2019 (UTC)

@@ Line 48: / Line 48: @@
 '.145 asks, perhaps rhetorically, ''"Then why not just write "Ctrl+B"? You can't see the mouse either, but you know what "click" and "select" are referring to."''<br>
 '''First''' of all, it doesn't matter. The comic could also have illustrated use of a menu, but that wouldn't tell us anything about Randall's knowledge of the iconbutton or the keyboard shortcut. Without any information about this, it's not possible to make reasonable inferences about this, and so the explanation shouldn't even go there. '''Secondly,''' there are good reasons why an iconbutton makes more sense (not that I'm required to supply them); because keyboard shortcuts are not as discoverable as iconbuttons or menus (and menus take a lot of space that make them hard in a comic of small compact multiples like this one) that means more people are familiar with the menu or button than the keyboard shortcut, and indeed those who know the keyboard shortcut are generally a subset of those who know another method; and further still, "Ctrl+B" is not platform-independent (e.g. Mac users need Cmd+B) or software-independent (InDesign users need Cmd+Shift+B). '''Thirdly,''' you can indeed see the mouse pointer, so I'm not sure what '.145 is trying to suggest. '''And finally,''' it's utterly ridiculous and kind of offensive to suggest (without any real basis) that Randall doesn't know how to use a word processor. That a person chooses to use one method, even if it's not the most efficient method, doesn't mean they are "not familiar with using word processors." We don't even know what Randall's UI preferences are here, but even if we did that wouldn't be enough to suggest a lack of familiarity rather than a personal preference. The text from [https://www.explainxkcd.com/wiki/index.php?title=2109:_Invisible_Formatting&diff=next&oldid=170285 this edit] is not encyclopedic and should stay out. [[User:JohnHawkinson|JohnHawkinson]] ([[User talk:JohnHawkinson|talk]]) 14:48, 4 March 2019 (UTC)
 In LibreOffice Writer on Linux if I select a word with double-click it doesn't include the space, but if I select it with the keyboard using Ctrl+Shift+RightArrow it '''does''' include the space. In the comic it looks like the selection was made with the mouse, but it's not explicit. [[Special:Contributions/172.68.189.193|172.68.189.193]] 00:15, 11 July 2019 (UTC)

← Older revision		Revision as of 00:15, 11 July 2019
Line 48:		Line 48:
	'.145 asks, perhaps rhetorically, ''"Then why not just write "Ctrl+B"? You can't see the mouse either, but you know what "click" and "select" are referring to."''<br>		'.145 asks, perhaps rhetorically, ''"Then why not just write "Ctrl+B"? You can't see the mouse either, but you know what "click" and "select" are referring to."''<br>
	'''First''' of all, it doesn't matter. The comic could also have illustrated use of a menu, but that wouldn't tell us anything about Randall's knowledge of the iconbutton or the keyboard shortcut. Without any information about this, it's not possible to make reasonable inferences about this, and so the explanation shouldn't even go there. '''Secondly,''' there are good reasons why an iconbutton makes more sense (not that I'm required to supply them); because keyboard shortcuts are not as discoverable as iconbuttons or menus (and menus take a lot of space that make them hard in a comic of small compact multiples like this one) that means more people are familiar with the menu or button than the keyboard shortcut, and indeed those who know the keyboard shortcut are generally a subset of those who know another method; and further still, "Ctrl+B" is not platform-independent (e.g. Mac users need Cmd+B) or software-independent (InDesign users need Cmd+Shift+B). '''Thirdly,''' you can indeed see the mouse pointer, so I'm not sure what '.145 is trying to suggest. '''And finally,''' it's utterly ridiculous and kind of offensive to suggest (without any real basis) that Randall doesn't know how to use a word processor. That a person chooses to use one method, even if it's not the most efficient method, doesn't mean they are "not familiar with using word processors." We don't even know what Randall's UI preferences are here, but even if we did that wouldn't be enough to suggest a lack of familiarity rather than a personal preference. The text from [https://www.explainxkcd.com/wiki/index.php?title=2109:_Invisible_Formatting&diff=next&oldid=170285 this edit] is not encyclopedic and should stay out. [[User:JohnHawkinson\|JohnHawkinson]] ([[User talk:JohnHawkinson\|talk]]) 14:48, 4 March 2019 (UTC)		'''First''' of all, it doesn't matter. The comic could also have illustrated use of a menu, but that wouldn't tell us anything about Randall's knowledge of the iconbutton or the keyboard shortcut. Without any information about this, it's not possible to make reasonable inferences about this, and so the explanation shouldn't even go there. '''Secondly,''' there are good reasons why an iconbutton makes more sense (not that I'm required to supply them); because keyboard shortcuts are not as discoverable as iconbuttons or menus (and menus take a lot of space that make them hard in a comic of small compact multiples like this one) that means more people are familiar with the menu or button than the keyboard shortcut, and indeed those who know the keyboard shortcut are generally a subset of those who know another method; and further still, "Ctrl+B" is not platform-independent (e.g. Mac users need Cmd+B) or software-independent (InDesign users need Cmd+Shift+B). '''Thirdly,''' you can indeed see the mouse pointer, so I'm not sure what '.145 is trying to suggest. '''And finally,''' it's utterly ridiculous and kind of offensive to suggest (without any real basis) that Randall doesn't know how to use a word processor. That a person chooses to use one method, even if it's not the most efficient method, doesn't mean they are "not familiar with using word processors." We don't even know what Randall's UI preferences are here, but even if we did that wouldn't be enough to suggest a lack of familiarity rather than a personal preference. The text from [https://www.explainxkcd.com/wiki/index.php?title=2109:_Invisible_Formatting&diff=next&oldid=170285 this edit] is not encyclopedic and should stay out. [[User:JohnHawkinson\|JohnHawkinson]] ([[User talk:JohnHawkinson\|talk]]) 14:48, 4 March 2019 (UTC)
		+	In LibreOffice Writer on Linux if I select a word with double-click it doesn't include the space, but if I select it with the keyboard using Ctrl+Shift+RightArrow it '''does''' include the space. In the comic it looks like the selection was made with the mouse, but it's not explicit. [[Special:Contributions/172.68.189.193\|172.68.189.193]] 00:15, 11 July 2019 (UTC)

@@ Line 44: / Line 44: @@
 I found (and find) the typography in this comic troubling, because while it is clearly a proportionally spaced font ("l" is 5px wide, "w" is 23px), the boldfaced and roman "not"s are the same size (49px wide). In a normal proportionally spaced situation, the boldfaced letters would be wider. [[User:JohnHawkinson|JohnHawkinson]] ([[User talk:JohnHawkinson|talk]]) 03:23, 23 February 2019 (UTC)
-In an edit last week I removed the claims that  "Randall bolds text via clicking" and that it "could indicate that Randall is not familiar with using word processors." [[Special:Contributions/172.68.144.145 172.68.144.145]] just reverted my removal, and I wanted to explain here why '.145 is wrong, in a little more space than the edit summary allows.
+In an edit last week I removed the claims that  "Randall bolds text via clicking" and that it "could indicate that Randall is not familiar with using word processors." [[Special:Contributions/172.68.144.145|172.68.144.145]] just reverted my removal, and I wanted to explain here why '.145 is wrong, in a little more space than the edit summary allows.
 I said originally, ''"An iconbutton is used for bold in comics for illustrative purposes, because you can't see the keyboard. It does not reflect the author-artist's knowlege."'' That is, we cannot draw conclusions about Randall's knowledge based on the fact that he didn't illustrate in this comic using a keyboard.<br>
 '.145 asks, perhaps rhetorically, ''"Then why not just write "Ctrl+B"? You can't see the mouse either, but you know what "click" and "select" are referring to."''<br>
 '''First''' of all, it doesn't matter. The comic could also have illustrated use of a menu, but that wouldn't tell us anything about Randall's knowledge of the iconbutton or the keyboard shortcut. Without any information about this, it's not possible to make reasonable inferences about this, and so the explanation shouldn't even go there. '''Secondly,''' there are good reasons why an iconbutton makes more sense (not that I'm required to supply them); because keyboard shortcuts are not as discoverable as iconbuttons or menus (and menus take a lot of space that make them hard in a comic of small compact multiples like this one) that means more people are familiar with the menu or button than the keyboard shortcut, and indeed those who know the keyboard shortcut are generally a subset of those who know another method; and further still, "Ctrl+B" is not platform-independent (e.g. Mac users need Cmd+B) or software-independent (InDesign users need Cmd+Shift+B). '''Thirdly,''' you can indeed see the mouse pointer, so I'm not sure what '.145 is trying to suggest. '''And finally,''' it's utterly ridiculous and kind of offensive to suggest (without any real basis) that Randall doesn't know how to use a word processor. That a person chooses to use one method, even if it's not the most efficient method, doesn't mean they are "not familiar with using word processors." We don't even know what Randall's UI preferences are here, but even if we did that wouldn't be enough to suggest a lack of familiarity rather than a personal preference. The text from [https://www.explainxkcd.com/wiki/index.php?title=2109:_Invisible_Formatting&diff=next&oldid=170285 this edit] is not encyclopedic and should stay out. [[User:JohnHawkinson|JohnHawkinson]] ([[User talk:JohnHawkinson|talk]]) 14:48, 4 March 2019 (UTC)

← Older revision		Revision as of 14:48, 4 March 2019
Line 43:		Line 43:

	I found (and find) the typography in this comic troubling, because while it is clearly a proportionally spaced font ("l" is 5px wide, "w" is 23px), the boldfaced and roman "not"s are the same size (49px wide). In a normal proportionally spaced situation, the boldfaced letters would be wider. [[User:JohnHawkinson\|JohnHawkinson]] ([[User talk:JohnHawkinson\|talk]]) 03:23, 23 February 2019 (UTC)		I found (and find) the typography in this comic troubling, because while it is clearly a proportionally spaced font ("l" is 5px wide, "w" is 23px), the boldfaced and roman "not"s are the same size (49px wide). In a normal proportionally spaced situation, the boldfaced letters would be wider. [[User:JohnHawkinson\|JohnHawkinson]] ([[User talk:JohnHawkinson\|talk]]) 03:23, 23 February 2019 (UTC)
		+
		+	In an edit last week I removed the claims that "Randall bolds text via clicking" and that it "could indicate that Randall is not familiar with using word processors." [[Special:Contributions/172.68.144.145 172.68.144.145]] just reverted my removal, and I wanted to explain here why '.145 is wrong, in a little more space than the edit summary allows.
		+	I said originally, ''"An iconbutton is used for bold in comics for illustrative purposes, because you can't see the keyboard. It does not reflect the author-artist's knowlege."'' That is, we cannot draw conclusions about Randall's knowledge based on the fact that he didn't illustrate in this comic using a keyboard.<br>
		+	'.145 asks, perhaps rhetorically, ''"Then why not just write "Ctrl+B"? You can't see the mouse either, but you know what "click" and "select" are referring to."''<br>
		+	'''First''' of all, it doesn't matter. The comic could also have illustrated use of a menu, but that wouldn't tell us anything about Randall's knowledge of the iconbutton or the keyboard shortcut. Without any information about this, it's not possible to make reasonable inferences about this, and so the explanation shouldn't even go there. '''Secondly,''' there are good reasons why an iconbutton makes more sense (not that I'm required to supply them); because keyboard shortcuts are not as discoverable as iconbuttons or menus (and menus take a lot of space that make them hard in a comic of small compact multiples like this one) that means more people are familiar with the menu or button than the keyboard shortcut, and indeed those who know the keyboard shortcut are generally a subset of those who know another method; and further still, "Ctrl+B" is not platform-independent (e.g. Mac users need Cmd+B) or software-independent (InDesign users need Cmd+Shift+B). '''Thirdly,''' you can indeed see the mouse pointer, so I'm not sure what '.145 is trying to suggest. '''And finally,''' it's utterly ridiculous and kind of offensive to suggest (without any real basis) that Randall doesn't know how to use a word processor. That a person chooses to use one method, even if it's not the most efficient method, doesn't mean they are "not familiar with using word processors." We don't even know what Randall's UI preferences are here, but even if we did that wouldn't be enough to suggest a lack of familiarity rather than a personal preference. The text from [https://www.explainxkcd.com/wiki/index.php?title=2109:_Invisible_Formatting&diff=next&oldid=170285 this edit] is not encyclopedic and should stay out. [[User:JohnHawkinson\|JohnHawkinson]] ([[User talk:JohnHawkinson\|talk]]) 14:48, 4 March 2019 (UTC)

← Older revision		Revision as of 03:23, 23 February 2019
Line 41:		Line 41:

	Seems to me that everybody here misses the point of the comic. Which is not the problems hidden left over formatting could do to later text. The joke here is that Randall is about to write something where he really means that '''NOT'''. But then regrets it, as he is afraid that the reader of his text/message would take offense of having this not shouted out in bold! So he reverts the bold, but because he misses the space, he has left a proof that he actually did mean '''Not''' and this can now be found out by the receiver anyway, which might then take offense anyway, or take offense that Randall felt he had to delete the bold, as if the receiver could not handle this (of course if he took offense from this Randall had proved his point, but never the less he tries to avoid this.). All this is mentioned now at the very end of a long list of indifferent problems such a bold space could create. I will move this up to the top now, as the main explanation. --[[User:Kynde\|Kynde]] ([[User talk:Kynde\|talk]]) 10:06, 13 February 2019 (UTC)		Seems to me that everybody here misses the point of the comic. Which is not the problems hidden left over formatting could do to later text. The joke here is that Randall is about to write something where he really means that '''NOT'''. But then regrets it, as he is afraid that the reader of his text/message would take offense of having this not shouted out in bold! So he reverts the bold, but because he misses the space, he has left a proof that he actually did mean '''Not''' and this can now be found out by the receiver anyway, which might then take offense anyway, or take offense that Randall felt he had to delete the bold, as if the receiver could not handle this (of course if he took offense from this Randall had proved his point, but never the less he tries to avoid this.). All this is mentioned now at the very end of a long list of indifferent problems such a bold space could create. I will move this up to the top now, as the main explanation. --[[User:Kynde\|Kynde]] ([[User talk:Kynde\|talk]]) 10:06, 13 February 2019 (UTC)
		+
		+	I found (and find) the typography in this comic troubling, because while it is clearly a proportionally spaced font ("l" is 5px wide, "w" is 23px), the boldfaced and roman "not"s are the same size (49px wide). In a normal proportionally spaced situation, the boldfaced letters would be wider. [[User:JohnHawkinson\|JohnHawkinson]] ([[User talk:JohnHawkinson\|talk]]) 03:23, 23 February 2019 (UTC)

← Older revision		Revision as of 10:06, 13 February 2019
Line 37:		Line 37:

	GIMP is really bad about this when trying to add text to an image. You either end up with the formatting not wanting to stick, or you end up with invisible formatting all over the place. [[User:Dark\|Dark]] <sup>[[User Talk:Dark\|talk]]</sup> 00:15, 11 February 2019 (UTC)		GIMP is really bad about this when trying to add text to an image. You either end up with the formatting not wanting to stick, or you end up with invisible formatting all over the place. [[User:Dark\|Dark]] <sup>[[User Talk:Dark\|talk]]</sup> 00:15, 11 February 2019 (UTC)
		+
		+
		+
		+	Seems to me that everybody here misses the point of the comic. Which is not the problems hidden left over formatting could do to later text. The joke here is that Randall is about to write something where he really means that '''NOT'''. But then regrets it, as he is afraid that the reader of his text/message would take offense of having this not shouted out in bold! So he reverts the bold, but because he misses the space, he has left a proof that he actually did mean '''Not''' and this can now be found out by the receiver anyway, which might then take offense anyway, or take offense that Randall felt he had to delete the bold, as if the receiver could not handle this (of course if he took offense from this Randall had proved his point, but never the less he tries to avoid this.). All this is mentioned now at the very end of a long list of indifferent problems such a bold space could create. I will move this up to the top now, as the main explanation. --[[User:Kynde\|Kynde]] ([[User talk:Kynde\|talk]]) 10:06, 13 February 2019 (UTC)