Talk:Diameter

Not manual

Per WP:NOTMANUAL, we don't generally include a list of instructions on how to type a character. Before I attempted to clean it up, the section on encodings had this level of detail:

The symbol has a Unicode code point at U+2300 ⌀ DIAMETER SIGN, in the Miscellaneous Technical set. On an Apple Macintosh, the diameter symbol can be entered via the character palette (this is opened by pressing ⌥ Opt⌘ CmdT in most applications), where it can be found in the Technical Symbols category. In Unix/Linux/ChromeOS systems, it is generated using Ctrl+⇧ Shift+U 2300space. It can be obtained in Unix-like operating systems using a Compose key by pressing, in sequence, Composedi. In Windows, it can be entered in most programs with Alt code 8960.

The character will sometimes not display correctly, however, since many fonts do not include it. In many situations, the Nordic letter ø at Unicode U+00F8 ø LATIN SMALL LETTER O WITH STROKE (ø) is an acceptable substitute. It can be entered on a Macintosh by pressing ⌥ OptO (the letter o, not the number 0). In Unix/Linux/ChromeOS systems, it is generated using Ctrl+⇧ Shift+U F8space or Composeo/. AutoCAD uses U+2205 ∅ EMPTY SET available as a shortcut string %%c.

In Microsoft Word, the diameter symbol can be acquired by typing 2300 and then pressing Alt+X.

In LaTeX, the diameter symbol can be obtained with the command \diameter from the "wasysym" package.

References

As I understand it, there are two, possibly three ways to encode the character: U+2300 in Unicode, the command \diameter in LaTeX and (arguably), &&C in AutoCad.

AFAICS, going into the detail of how to implement those encodings in a document falls foul of WP:NOTHOWTO. We should just refer readers to relevant articles such as Unicode input and LaTeX. So I'm at a loss to understand why user:Spitzak believes that the compose key material should be restored and user:David Eppstein believes the same about the information on how to write LaTeX. Since I have the greatest respect for both of these editors, I have to wonder it is that I am missing. What is unique about this case? and if these two are to be reinstated, then surely the Windows and MacOS instructions should be reinstated too? 𝕁𝕄𝔽 (talk) 22:55, 4 May 2024 (UTC)

As far as I can tell, your reading of notmanual and nothowto is bogus. Encyclopedia articles should not read like tutorials, but this does not mean we are forbidden from explaining the how of an encyclopedic topic. We should not go step-by-step (first find the key marked with a cloverleaf symbol, then hold down that key and the Q key), but a concise explanation of how certain characters are encoded on the keyboards of commonly used systems, with sources, is perfectly appropriate. Or do you think that articles detailing how certain processes happen are somehow forbidden from Wikipedia? For instance, do you think we should not have an article long division because it is about how to calculate divisions and that word "how" makes it forbidden? Use your brain, think about what the guidelines mean, don't just blindly follow rules because you read them somewhere. If a rule comes across as an arbitrary prohibition rather than something that is going to improve the encyclopedicness of our coverage, you are probably reading it wrong. —David Eppstein (talk) 23:39, 4 May 2024 (UTC)

Personally, I think a detailed explanation about how to type the unicode glyph ⌀ in every environment seems out of scope for an article about the diameter of a circle. Explanations about how to insert unicode symbols on Mac, Windows, MS Word, etc. would probably be better to include somewhere such as Unicode input or Code point § In Unicode (or in the off-wiki user manuals about specific software applications), rather than redundantly at every article mentioning a unicode glyph. –jacobolus (t) 00:51, 5 May 2024 (UTC)

A general description of how to type unicode would make sense at those targets. But those general descriptions are not likely to tell you for instance that an eszet character can be obtained from option-s on Apple keyboards. Similarly, for this character the important part here is not how to use the compose key on Unix keyboards to obtain non-ASCII characters; it is that the compose code for this specific character is di. That is not even a "how to" piece of information. It is merely an association between two different systems of codes that otherwise might be difficult to find. If someone is looking up the diameter symbol, it might be because they remember that it has a compose code but not what it is. —David Eppstein (talk) 01:22, 5 May 2024 (UTC)

But that is the purpose of the Unicode input and compose key articles. It makes no sense to repeat the information at every article, with all the "if you have this keyboard, then do this; if you have that keyboard, then do that. Unless you have this other keyboard mapping. Or maybe a different code page". For example, if you have a QWERTZ keyboard, no gymnastics are required to get ß, you just press ß. To be fair, the Unicode input article is very thin on MacOS, but the solution is to fix that article once, not do it a hundred times in a hundred articles.

Clearly we have very different perceptions of the scope of NOTHOWTO, so I will ask at Wikipedia talk:What Wikipedia is not for a second opinion. --𝕁𝕄𝔽 (talk) 17:44, 5 May 2024 (UTC)

I'd have to agree with jacobolus that this seems out of scope of the article. Where would this stop, what of common mobile keyboards such as the iPhone, Samsung keyboard for Android, or GBoard, what of common accessibility keyboard. -- LCU ActivelyDisinterested «@» °∆t° 18:51, 5 May 2024 (UTC)

It makes no sense to argue that we should suppress this sourced information about how the unicode and compose-key-code are connected. It has nothing to do with NOTHOWTO because it is not even how to press the compose key, merely the fact that this character has this compose-key-code. It makes no sense to say that this information can only be in one place on the encyclopedia, because it is neither desirable not commonly followed to ensure that each encyclopedic claim appears only in one place. And it makes even less sense to say that this information should not appear here because other articles have the purpose of providing that information, when in fact this information appears nowhere on those other articles (and should not; we should not have an article providing the methods for inputting all possible unicode characters, as that would actually violate NOTHOWTO). As for your Whataboutism: we should only include sourced information about methods that are distinctive to this character, and not generic for all unicodes. For instance, the Apple keyboard (what I usually use) does not appear to have a shortcut for the diameter symbol (instead web sources suggest using the Danish slashed letter O, a different symbol) so we should not discuss how to get that symbol on Apple keyboards. —David Eppstein (talk) 19:18, 5 May 2024 (UTC)

But this isn't about reliable sources, it's about what should be included in this article. I sure reliable sources could be found on how to type the diameter sign on a multitude of different keyboards, that isn't a definitive reason to include the information in this specific article. -- LCU ActivelyDisinterested «@» °∆t° 21:10, 5 May 2024 (UTC)

Notice that before JMF's edits there was quite a lot of detail. [Edit: rm. re-quoted context that I just realized JMF already quoted at the top of this thread. I apparently skimmed right past it when reading before.]

If there's an article dedicated to the symbol ⌀, or to a group of related symbols, then it's fair enough to elaborate about it. I think it's off-topic / out of scope at an article about the diameter of a circle. I extended the discussion of LaTeX a bit, but frankly the whole discussion about that is also perhaps excessive here. It might be better to move this material to some other article about technical symbols, and just link it from here.

At this article, I would mention that there is a diameter symbol ⌀, describe how it is used to mean 'diameter' in technical drawings but rarely in other contexts, briefly mention what it's unicode name / code point is and that it's similar looking to the empty set symbol ∅, with relative appearance of the two varying from font to font. –jacobolus (t) 19:26, 5 May 2024 (UTC)

I have no interest in restoring that additional detail, but this discussion was sparked by the restoration of a single sourced line from it, the line about how the diameter symbol is coded as compose-d-i. I think it would be nonsensical to suppress that line. The rest of the information you quote is mostly generic to all unicodes, not specific to this article, and was correctly removed. —David Eppstein (talk) 19:28, 5 May 2024 (UTC)

I don't think we currently have any article about writing conventions and symbols used in technical drawings, but I think all of this info would be more relevant at such an article than here. –jacobolus (t) 20:47, 5 May 2024 (UTC)

Even if there was a standalone article about that symbol, the full instructions of how to type it would be out of scope. Instead, a page about, for example, LaTeX, it would be fair to include a list of codes and brief instructions how they are entered on various systems, such that there is only one place on WP where these instructions would make sense.
I absolutely agree the inclusion here fails NOTHOWTO. — Masem (t) 20:04, 5 May 2024 (UTC)

I also agree; this is exactly what NOTHOWTO indicates should not go in articles. If any portion of an article reads like a tutorial or manual, it almost certainly violates NOTHOWTO. That doesn't mean the information is of no value, it's just out of scope for Wikipedia. Seraphimblade ^{Talk to me} 20:13, 5 May 2024 (UTC)

Thanks, Jacobolus, for confusing the issue by providing a big example of stuff not to include that everyone can agree not to include so that we have no idea whether the responses are about that big example or about the content actually under dispute. User:Masem and User:Seraphimblade, can you be more specific about whether it is off-topic to state the unicode code point of a symbol on an article (or in this case the target of a redirect diameter symbol) about that symbol (without detail about how one types unicode code points)? If not, can you explain what you think is different about stating the compose code abbreviation for the same symbol (again, without detail about how one types compose codes)? —David Eppstein (talk) 20:21, 5 May 2024 (UTC)

The sarcasm is entirely unnecessary. Thanks. –jacobolus (t) 20:38, 5 May 2024 (UTC)

Yes, and I don't appreciate being told I'm confused. If there is any material telling the reader "Here's instructions for how you _________", large or small, that is out of scope for the article. That includes the long digression, and it also includes the current "It can be obtained in Unix-like operating systems using Compose-d-i", which also needs to be removed. I do actually read things before I comment on them, and I was not in any way confused. If I was, I would have asked for clarification. Seraphimblade ^{Talk to me} 20:42, 5 May 2024 (UTC)

So you object to saying that people can do things, even in passive voice? So on ballot, you would object to the line "Each voter uses one ballot, and ballots are not shared." because that might be interpreted as instructions to readers on how to vote? That is a completely nonsensical view of NOTHOWTO. It is frequently the case that ways of doing things are topics of encyclopedic content. "How" is one of the fundamental questions encyclopedias answer, along with "what", "when", "where", "why", and "who". Is it the verb "can be obtained" that you object to? If we rephrased it in a way that eliminated any possibility of being interpreted as an instruction, would that satisfy you? Something like

It has the compose sequence compose-d-i.

? —David Eppstein (talk) 20:48, 5 May 2024 (UTC)

A discussion of how the symbol is made on keyboards might be in scope for an article on the symbol itself, if it's notable enough for one. But it is excess detail for an article about the concept of diameter in general. Seraphimblade ^{Talk to me} 20:51, 5 May 2024 (UTC)

I'm not too worried about the scope or details of the "nothowto" policy per se, and focusing on that seems like a distraction. The question for me is: Should we expect that someone trying to type the symbol ⌀ in Linux should be looking for that info in a Wikipedia article about the diameter of a circle, and should we expect any substantial portion of the readers of an article about the diameter of a circle to be interested in how to type the symbol ⌀ in Linux? –jacobolus (t) 20:55, 5 May 2024 (UTC)

In fact I am worried about nothowto, because the subject of my professional research is algorithms, and an obtuse flat never-on-Wikipedia interpretation of nothowto would seem to forbid all articles about algorithms. When interpreted as meaning "don't write in the style of a user guide" (as your long block example here did), nothowto is fine. When interpreted as meaning "suppress any information that readers might use to learn how to do things", it is bad and should be fought hard at all turns. —David Eppstein (talk) 21:08, 5 May 2024 (UTC)

Well, I don't think there is any harm if this article, for example, explains how the diameter of a circle is calculated (at least in general, though not step-by-step instructions). That's an entirely valid thing to be in an article about diameter. But this article is not about the diameter symbol. Noting that there is a symbol for diameter is valid in this article, but detail on how to type it on various operating systems (and why just *nix? Why not Windows, or MacOS/iOS, or anything else?) is not in the scope of this article. Seraphimblade ^{Talk to me} 21:20, 5 May 2024 (UTC)

An algorithm is exactly "step-by-step instructions". You are still taking a position I abhor, that any form of step-by-step instructions are forbidden. One cannot describe an algorithm accurately without stating it in the form of step-by-step instructions. You are parroting the bad side of nothowto, the side that is about content rather than style. —David Eppstein (talk) 21:29, 5 May 2024 (UTC)

@David Eppstein I feel like you are ignoring people's point to focus on straw-man hypotheticals. Nobody is suggesting removing descriptions of algorithms from articles about those algorithms. We're talking about removing detailed descriptions about input of a symbol which was shoehorned into a substantially unrelated article.

My proposal to resolve this would be to create a stub article diameter symbol, and move this information there. –jacobolus (t) 22:47, 5 May 2024 (UTC)

If you think this is a strawman then you need to explain it to me in a way that makes sense.

Currently we have a lot of people arguing that a code for a character (the code compose-d-i) should be removed, using NOTHOWTO as justification. There is nothing user-guide-like in the way the code is described. It does not say anything about pressing keys. It does not even tell readers what a compose sequence might be used for. It just states the sequence. Nevertheless, we still have NOTHOWTO invoked as the justification.

I don't understand it. If NOTHOWTO is merely the guidance not to write like a user guide, we are already following it. The only other explanation I can find to motivate these comments is that compose-sequences are things people use to do things, and that NOTHOWTO forbids us from writing anything that could be interpreted as describing how people do things. So if a code is not merely a code, but also a sequence of keypresses, then we must suppress that code, because people might press those keys in that sequence, and then they would learn something about how to do things from the encyclopedia. We can't have that. It is that interpretation that I am strongly against.

Maybe there is some other motivation that I am missing. Maybe there is some other explanation for why mentioning a character code is forbidden when that code happens to be a compose sequence but allowed when that code happens to be a unicode; I asked above for something that would differentiate those two cases but everyone I asked avoided that topic. If you can provide an explanation, please do.

As for moving it to a separate stub: I am not opposed, but I am also not convinced that (even after my improvements to use several book sources) we have enough depth of coverage to make a separate article that would survive an AfD. —David Eppstein (talk) 23:15, 5 May 2024 (UTC)

Unicode is universal and XCompose is not. Remsense诉 23:20, 5 May 2024 (UTC)

Would that sentence be any more meaningful if you wrote "Unicode is universal and EBCDIC is not" or "Unicode is universal and non-numeric html entities are not"? What is the relevance of universality here? —David Eppstein (talk) 23:33, 5 May 2024 (UTC)

I am not sure any more. I think your point below about text encoding broadly construed is worthwhile, which is why I was mulling the viability of a dedicated reference page that could list this information in a way that suits readers and is WP:DUE. If someone is interested in the code for one symbol, isn't it likely they would be interested in the code for several related symbols? Remsense诉 23:38, 5 May 2024 (UTC)

At one point I thought we had this example, but it is one thing to say "Chicken soup is typically made from chicken broth, chicken meat, noodles, and a variety of spices", and "You make chicken soup by adding 1 cup of cut chicken to 2 quarts of chicken stock, then 1/2 tablespoon salt...(etc.)". The first is an encyclopedic line, just as saying the diameter symbol has a specific Unicode number or LaTex symbol, or how a typical democratic vote process works; verses detailed instructions for how to enter the symbol or explaining how one locates their specific voting place and what they are expected to do there. Masem (t) 20:57, 5 May 2024 (UTC)

Also, as someone who loves their compose key to death: pretending WP:NOTHOWTO doesn't exist for a second: their use is simply not prevalent enough to include on almost any article not directly related to computer input, full stop. Remsense诉 21:00, 5 May 2024 (UTC)

Certainly if this article were only about diameters, and not about the diameter symbol, I would not include it. But the fact remains that this is the only Wikipedia article about the diameter symbol. We could discuss splitting it off into a separate article but that would require better sourcing than we currently have. —David Eppstein (talk) 21:11, 5 May 2024 (UTC)

The article that best includes info on the diameter symbol is Glossary of mathematical symbols, not this article. Masem (t) 21:18, 5 May 2024 (UTC)

Perhaps you can rephrase that in a way that does not imply that every claim on Wikipedia can only appear in a single article. Because I have good faith that you would not take such an extreme position, but I am not getting that from your comment here. How is a reader, looking up diameter symbol, to guess that this information might instead be found somewhere else (in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard")?

Do you, perhaps, mean instead that all the details about the diameter symbol, and the redirect target for diameter symbol, would all be better moved to that glossary? So that readers looking up diameter symbol would find that information there, and not come here at all? But that glossary does not appear to list even the unicodes for its entries (it is more about notation than about characters). —David Eppstein (talk) 21:21, 5 May 2024 (UTC)

Just because a plausible redirect exists does not mean by itself that the target of the redirect is to be considered a distinct subject upon scrutiny. Also, here's a direct answer to the question: how about a hatnote to Glossary of mathematical symbols § ⌀, or an equivalent that does effectively juxtapose this information. That seems like a solution everyone present would be mighty happy with. Remsense诉 21:26, 5 May 2024 (UTC)

So you are proposing to rewrite glossary of mathematical symbols in its entirety, to discuss symbol encodings for all the symbols it describes? Or are you proposing to sweep the encoding under the rug by saying it can only go on some other article where it cannot go and therefore we cannot discuss encodings at all, anywhere? Not even the unicode? —David Eppstein (talk) 21:32, 5 May 2024 (UTC)

Possibly the former, possibly a new page, I am not sure. (Glossary is a coherent type of reference work, why not 'technical glossary'?) Not the latter, as I think the UTF encoding is DUE for any section discussing symbols. Remsense诉 21:38, 5 May 2024 (UTC)

This is not really a "mathematical symbol". I have personally never seen this symbol used in a mathematical work (though it's certainly possible someone has somewhere), after reading lots and lots of works about circles and spheres. It's a symbol used to indicate measurements in technical drawings.

The ideal home for this would be an article about the typography of technical drawings, but we don't currently have one. –jacobolus (t) 23:50, 5 May 2024 (UTC)

Well, not only technical drawings. See the sentence about camera lens filter diameter markings. —David Eppstein (talk) 23:59, 5 May 2024 (UTC)

Maybe to be more precise: this symbol is an abbreviation for the word "diameter" in the context of engineering/technical materials including blueprints, specification sheets, manuals, ... Maybe Geometric dimensioning and tolerancing § Symbols would be a reasonable home. –jacobolus (t) 00:03, 6 May 2024 (UTC)

That...makes more sense than in an article about diameters in geometry, actually. —David Eppstein (talk) 00:33, 6 May 2024 (UTC)

Or do you think that articles detailing how certain processes happen are somehow forbidden from Wikipedia? For instance, do you think we should not have an article long division because it is about how to calculate divisions and that word "how" makes it forbidden?

There's a pretty clear distinction between these two examples: the process of long division is itself the subject of the latter example. The subject of this article is not that of Input methods, and these inclusions seem parochial to me, as if seeking to address what is seen as an omission in how the subject has been described to date. If this were apropos for the subject Diameter, our sources would include something like it; instead it is clear to me they were added mostly because they seemed a "bonus" for the reader, rather than reflecting the subject as covered in sources. Remsense诉 20:50, 5 May 2024 (UTC)

The subject of diameter symbol is, exactly, the diameter symbol. It happens to be a redirect, but it still needs to be treated encyclopedia at that redirect target, like our other content about symbols. —David Eppstein (talk) 21:05, 5 May 2024 (UTC)

The subject is diameter, with the symbol not being sufficiently distinct to warrant its own article. This seems a trivial understanding of N and DUE. Remsense诉 21:14, 5 May 2024 (UTC)

Given that it was I who invited second opinions on the scope of NOTHOWTO, may I make clear that my concern is for the general point, not specifically about the concept of 'diameter' and its specific symbol. So may I choose a better example that I think will make clearer the different perspective held by David E and me: the eszet character (ß). As I understand David's view, that article should contain information on how to enter it if you don't have a QWERTZ keyboard. My view is that readers should be referred for that information to an article that specialises in such questions, for all non-ASCII characters. Does that illustrate the issue more clearly? --𝕁𝕄𝔽 (talk) 22:31, 5 May 2024 (UTC)

Yes. My position is that not much more than the UTF codepoint should be explicated in generalized articles or sections on symbols themselves, and that a specialized article of some kind should be referenced instead. Remsense诉 22:43, 5 May 2024 (UTC)

JMF, that is a mischaracterization of my view. I am not particularly interested in providing a compendium of methods for finding and entering the eszet character on different systems; that might indeed fall afoul of NOTHOWTO. But, when we are writing about a character, we should write about its encoding in notable systems for encoding characters. Unicode is one such system, but not the only one. For instance, the eszet article also mentions its encoding as an html entity. I have not ever used compose sequences, but I was under the impression that compose sequences can also be thought of as a system for encoding characters, at least temporarily before they are translated into something more suitable for file storage. Is it not a notable system for encoding characters? Does the fact that it can be entered directly somehow taint it? If I enter unicodes directly on my keyboard using numeric codes, does it taint them, too, so that they could not be mentioned either? —David Eppstein (talk) 23:28, 5 May 2024 (UTC)

I entirely disagree with this one JMF. How Eszet is handled by various systems (the whole history of the treatment of this character by systems from 19th century telegraphs up through present computer software) is clearly in scope for an article about Eszet, and coverage should be as comprehensive as any editor is motivated to track down reliable sources for. This shows pretty well why WP:NOTHOWTO is not really the right reason for rejecting this information here. If we want a little wiki-insider abbreviation, I would list WP:DUE and WP:COATRACK. –jacobolus (t) 23:54, 5 May 2024 (UTC)

@David Eppstein perhaps my failed attempt to summarise your position may help explain our difference of view. But first a clarification: the html code is not unique, it is just another way of presenting the Unicode code-point value. Nor are compose sequences unique: these too are ways of presenting or requesting the unicode code-point – no different in concept to using AltGr+s or ⌥ Option+s. [Diameter, oth, is special because LaTeX and AutoCAD are not using Unicode, they are drawing the glyph in a different way. These are unique encoding methods.]

@Jacobolus, you illustrate why I chose a new example – because it was getting sidetracked into discussing the main body of the article. In each case, there is a valid article about the concept and/or history behind character. But this discussion is on encoding(s) of the character. In the case of Eszet, there is only one – Unicode (including its integrated predecessor, ISO Latin-1). The dispute is whether the section should go on the explain how to type that symbol into your essay. 𝕁𝕄𝔽 (talk) 08:33, 6 May 2024 (UTC)

@David Eppstein, just to clarify the html question, take another example: basis point (U+2031 ‱ PER TEN THOUSAND SIGN). You can write it as &#x2031, &#8241 or the mnemonic &pertenk: all are equally ways to represent the same binary code recognised by the text rendering engine. (As before, LaTeX and AutoCAD use very different engines.) 𝕁𝕄𝔽 (talk) 11:51, 6 May 2024 (UTC)

This is a poor example in my opinion. The per ten thousand sign is not actually used for basis points. It seems self evident to me that discussion of this symbol per se belongs at percent sign, not at basis point. If placed in a section of percent sign, it would be fine in my opinion to discuss various ways of encoding the symbol in HTML, etc. Discussion of the ins and outs of this symbol seems clearly out of scope for the article basis point as used in finance, where this symbol never appears. –jacobolus (t) 14:45, 6 May 2024 (UTC)

Re the number 0.0001, how is your comment remotely relevant to the question of what the encoding section should contain? --𝕁𝕄𝔽 (talk) 17:07, 6 May 2024 (UTC)

In my opinion, text encoding and input is clearly directly relevant to an article about percent sign or ‱ as a symbol per se, but is entirely off topic and inappropriate in an article about basis points. –jacobolus (t) 18:53, 6 May 2024 (UTC)

To me, all are equally valid ways of representing the glyph and its associated semantics. In the case of html entities, I believe they are defined to be shortcuts for unicodes. But in general there is no justification for conflating glyphs with unicodes. A system of coding glyphs may be intended to be used for translation into another system of coding glyphs (as non-numeric html entities to unicodes), it may directly represent another system of coding glyphs (as numeric html entities represent unicodes), or it may stand on its own. It may be intended to be used for human input (compose codes, Apple option codes), it may be intended only for internal storage (binary-represented unicodes), or it may be intended only for output (whatever coding was sent to a Compugraphic machine, etc). But to me the intended use of a system of coding glyphs is secondary to the fact that it is an organized system of coding glyphs. —David Eppstein (talk) 17:33, 6 May 2024 (UTC)

But in general there is no justification for conflating glyphs with unicodes. I agree completely! neither LaTeX nor AutoCAD use Unicode for the diameter glyph – and indeed the same is true in LaTeX for all the mathematical symbols.

&#x2031, ‱ and ‱ are identical and are the way to write the Unicode code-point in HTML – that is how its syntax works. They are not alternatives to Unicode, they are Unicode. Of course the code could be translated into another system but that is seriously out of scope, IMO. I don't understand your it may stand on its own. The ⌥ Option, Compose, AltGr, CharMap selection etc are input methods, designed to select the Unicode number. Whether that number is stored in a database (to represent a glyph) or is used to display or print it is not obviously significant: once it is captured, you do what you like with it.

I'm afraid that I don't follow your last point? Is it relevant to whether it is appropriate or not, to list in the #Encoding section of every article about every glyph, the details of all the input methods that can be used to encode it? --𝕁𝕄𝔽 (talk) 19:04, 6 May 2024 (UTC)

I don't understand why you want to single out input methods as not being encodings. They are encodings. The fact that they are (usually) immediately translated to a different encoding doesn't change that fact. —David Eppstein (talk) 20:19, 6 May 2024 (UTC)

Are we at cross-purposes with our use of the word encoding? According to Wiktionary:

encoding (plural encodings)
     1.  (computing) The way in which symbols are mapped onto bytes, e.g. in the rendering of a particular font, or in the mapping from keyboard input into visual text.
     2.  A conversion of plain text into a code or cypher form (for decoding by the recipient).

I have been using it in the first sense, the mapping of a human-readable symbol onto a machine-readable binary string. Are you using the second? (the process by which that mapping is achieved). --𝕁𝕄𝔽 (talk) 22:59, 6 May 2024 (UTC)

"the mapping from keyboard input into visual text" is directly there in your first definition. I really don't understand the confusion. –jacobolus (t) 23:24, 6 May 2024 (UTC)

But also, a compose sequence really is a mapping between symbols and sequences of bytes. As in, it corresponds the diameter symbol discussed in this article to the sequence of ASCII bytes d (100) i (105). To use this embedded within normal ASCII or Latin1 you would need some sort of convention for how to express the compose symbol but there are plenty of octets free as control symbols used for that.

Also, that is a ridiculously overspecific definition. Are six-bit or seven-bit ASCII (both in use on DEC 36-bit architectures in the 1970s and 1980s) somehow not encodings because they do not use 8-bit bytes? What about 10-bit encodings on punched cards? —David Eppstein (talk) 00:28, 7 May 2024 (UTC)

I am with David here, this distinction as presented seems arbitrary in the context of what it means for a page about a grapheme. My notion was more about the comparative use of encodings, i.e. pretty much just Unicode. Remsense诉 01:26, 7 May 2024 (UTC)

No, the article Eszett can (if someone tracks down reliable sources) discuss the history of the appearance of Eszett on various computer keyboards, whether and how it has been type-able when it didn't appear directly, how else it might be input if not type-able, how it was encoded (and not just in Latin-1 but also in whatever other character encoding), and so on. All of this is clearly encyclopedic. In an article scoped to be directly about the diameter symbol, such information would also be fine, in my opinion. –jacobolus (t) 14:37, 6 May 2024 (UTC)

Re Eszett, the material you have in mind would be a section in its own right. If you want to write such a section, you may find what you need at de:Schreibmaschine and QWERTZ. Again, how is it relevant to encoding and input methods? --𝕁𝕄𝔽 (talk) 17:07, 6 May 2024 (UTC)

Need Figure for Convex Shape in the Plane

The intro contains the following: "For a convex shape in the plane, the diameter is defined to be the largest distance that can be formed between two opposite parallel lines tangent to its boundary..." I haven't been able to decipher that. (I'm not a mathematician.) Sure would be helpful if someone added a figure to illustrate that. I picture the convex shape being a curve that is a fourth of a circle. Don't know what the "boundary" is, or how such a shape has two tangent lines that are parallel. Thanks!--Christopher King (talk) 21:38, 22 June 2024 (UTC)

A convex shape between two parallel supporting lines (but not a good example for this article because all support distances are equal). The convex shape is the whole yellow area. Its boundary is the black outline. —David Eppstein (talk) 23:04, 22 June 2024 (UTC)

Symbol for Average

At least in German, this symbol is also the symbol for an average, e.g. "⌀ goals per game in the last football season: 2.3". Isn't that also a thing outside of the German language? See http://de.wiki.x.io/wiki/Durchmesserzeichen#Mittelwert --2A02:8071:7012:2A20:1081:2774:D6DB:62CC (talk) 19:11, 19 August 2024 (UTC)

I have never seen that usage (California). –jacobolus (t) 19:57, 19 August 2024 (UTC)