# Markup for Overbars

In answers such as this and this I mention signals on chip pins and buses. Some of these signals are "active low," which are traditionally written with a overbar over the signal name. I'd like to be able to do that here.

Currently the best alternative convention supported here (which I'm using where I can) is to use a slash before the signal name, e.g., /CS for active-low chip select. But that runs into problems for signals that already have a slash in them, such as "read/not-write" where R//W is not really clear that one slash separates the two components and the second slash is negating the second component. Being able to write this as R/W with an overbar over the W would be a lot more clear.

This would also be handy on various other SE sites. Some SE sites, such as the EE StackExchange, allow LaTeX/math markup, which offers a way of doing this, but the markup is pretty awkward ($\small \overline{\text{CS}}\$). (Other sites where signal names are likely to be used are the Arduino and Raspberry Pi exchanges.)

There's easy HTML markup for an overbar: <span style=text-decoration:overline>CS</span> so I don't think that there's any issue on the display side, but there is the question of how to mark it up in the editor. What would it take to add this?

You can sort of do this with the following HTML markup:

C&#773;S&#773;


This renders like so:

C̅S̅

It doesn't really work on every browser (e.g. it completely fails on most Androids, and it displays funny on my machine) but it's perhaps the best we can do without MathJax. (A custom markup is almost certainly out of the question, but I haven't asked about it yet.)

This isn't enough on its own to justify getting MathJax, since it slows down the loading of every page and the rendering of many. However, these things build up, and we might've become a technical enough site to justify it now. Post another question with reasons and, if the rest of the community agrees, we can use that justification to convince SO to add it.

• Agreed, this isn't enough alone to justify the likes of Mathjax. If we are asking the question, is there enough momentum to ask for schematics like on the RPi site - raspberrypi.meta.stackexchange.com/q/2074/9362 ? I suspect we may have to be a graduated site to get either of them approved. – Chenmunka Nov 7 '18 at 9:34
• @Chenmunka We should be able to get MathJax (with sufficient justification) in beta, but I'm not sure about schematics. – wizzwizz4 Nov 7 '18 at 21:17
• This works great for me, and I had no issues in Chrome or Opera on my Android 7.1 phone. GitHub for some reason doesn't render them perfectly (often the overbar is offset to the right), so it seems somewhat site-dependent. I agree that MathJAX is awfully heavy just for this, and since this solution works well for me, I'm accepting it as solving my problem. – Curt J. Sampson Nov 8 '18 at 5:58
• I wish MathJax were added to all the SE sites. For a recent answer I posted on gis.se I ended up going over to math.se, entering some MathJax, taking a screenshot, then attaching that to my answer. – Alex Hajnal Nov 17 '18 at 1:49

Some of these signals are "active low," which are traditionally written with a overbar over the signal name.

That is just one convention. There are many more, and they are as well traditional ones. even in fact more traditional than an overbar. Using an overbar in traditional documentation was only possible when typeseted. Or added manually when it got printed by photographic means.

Currently the best alternative convention supported here (which I'm using where I can) is to use a slash before the signal name, e.g., /CS for active-low chip select.

Which is exactly the way such a signal is named in classic documentation or (most) tools using textual input (like PALASM).

But that runs into problems for signals that already have a slash in them, such as "read/not-write" where R//W is not really clear that one slash separates the two components and the second slash is negating the second component.

Well, only if the slash is interpreted as 'or'. But the signal is not the combination of two signals at different times, but two meanings when used. It's therefore not named "Read or Write" but reads correctly "R (not W)", or short is R/W. Adding here an overbar is just stating the obvious. If at all, the signal must be written RW with an overbar only above the W (RW̅)

Having said that, there are systems where different signals are transported over the same line at different situations. A good example would be the 8086es /RQ, /GT0 (on pin 31), which transports different signal at different times during a bus request cycle. It's a bidirectional line in addition. They are two independant signals and either signal is active-low. The name is often a concatenation of both for a pinout, but thurout all documentation described seperate. For a clear naming, this line should have had it's own name, but Intel went with a list - and using / as list seperator.

This 8086 pin is even more revealing, as in Minimum mode it becomes the active-high signal HOLD :)) Something that again gets handled during documentation seperate and marked on pinouts in many different ways.

Facit, as soon as something gets more sophisticated, notation isn't as clear anyway.

And then there is the even more important issue of copying text, which usually looses most of such eye candy, much depending on the readers system and the target application. While some charset based games may work out to some degree, everything HTML will result in a complete loss of information, even screwing it up big time (*1)

Bottom line: If we want to get readable and long time stable (*2) questions and answers it's best to stay with basic 7 bit encoding and well proven notations within this codeset. Adding eye candy is adding another point of failure.

*1 - Like 27 (2<SUP>7</SUP>) ending up as 27 ... doesn't look right, does it?

*2 - I don't think anyone can predict waht future environments will do with all these 'tricks' - just remember what features have already droped out of HTML (and SUP is one of the things they always want to get rid of, as it describes rendering, not content and rendering is meant to be done by CSS - right?)

• Most data sheets and typewritten documents I've seen that predate the common use of email and ASCII files for data exchange used overbars (drawn in by hand or typed as an underbar on the line above on the typewritten documents), as well as many since then. If you're going to claim that anything else was in common use during that period, it might be a good idea to provide examples. – Curt J. Sampson Nov 14 '18 at 6:50
• As for "R/W̅" vs. "RW̅", it may indeed be that you're correct and every data sheet I can remember that used a slash was wrong, but again, your argument would be more convincing with examples. I have seen regular use of "R/W" instead of "R/W̅", but in documents that otherwise used overbars for active-low signals. – Curt J. Sampson Nov 14 '18 at 6:50
• @CurtJ.Sampson The decisive argumentwasn't about the exact spelling, as there there where many, but that we should not use tools (like overbar-eye-cyndy) that can't transpose their meaning over to be expected handling. Device independant rendering and copying being the most obvious. The transport of plain unargumented ASCII is proven to work since 'ancient' times, and we may as well follow that example. (BTW, I can't remember seen the R//W spelling you propose even once in contemporary papers). – Raffzahn Nov 14 '18 at 8:53
• I would hope you never see that R//W spelling anywhere, since it's absolutely horrible. I think if you re-read my post carefully you'll realize that "I don't want to use that" is much more compatible with what I wrote than "I propose using that." As for overbars being "eye candy", well, that we both agree R//W (replacing the overbar with a leading slash) doesn't work kinda says they aren't just eye candy, doesn't it? – Curt J. Sampson Nov 15 '18 at 3:28
• Nor do I. I still read your post in a way that you would think abotu it as logic - even while being horrible. And overbars aren't eyecandy because of R/W, but because the whole idea of them being needed or part of a fixed system is an ilusion. They work in a stingent way when looking at some easy cases, but as shown (wih R/W being one of them), this doesn't extend far. It's much like accents on words to help pronounciations which usually can be droped anyway, versus pronounciation changing markings like umlauts. – Raffzahn Nov 15 '18 at 13:38
• Now, on a more technical base, a polarity (active state) can only be given for a single signal wich does carry an active/inactive meaning. More complex signals - like a serial line, or even the 8086es arbiting signals - can not be noted that way, as their meaning is time and direction dependant. More important here, even R/W can not be specified as such, as it does not have an acrive state per se. Either level is telling, much the same way an address or data line is - you can't give an active state for such either. R/W could as well be called DIR with no bar at all. – Raffzahn Nov 15 '18 at 13:46
• I've always used R/W for Low=Write and W/R for Low=Read. If I ever saw R//W I'd be reaching for the datasheet to see what was really meant. – Alex Hajnal Nov 17 '18 at 1:45