Handle !xx/!xx! inverted signal label display convention

[follower]

Currently the library does not display labels using the !xx or !xx! convention with the specified bar above the label.

Example of current display:

Photo of actual board with correct display:

[follower]

It appears the code that handles this is in EagleBrdRenderer.prototype.drawTexts().

We'll need to parse the label/legend text to determine which characters need the bar/line over them.

Apparently this is generically called an Overline and can be implemented with CSS using text-decoration: over line; or with Unicode. We'll need to ensure that the overline is contiguous and that position & character height is consistent with Eagle's rendering.

[dave5]

the css handling looks like it will do the correct thing...

unicode looks a bit iffy

[follower]

The drawTexts() method uses the fillText() method of a CanvasRenderingContext2D.

Unfortunately the text argument supplied to the fillText() method doesn't support text-decoration (semi-related)--although it does support Unicode (via \u{}) but as you've seen overline support doesn't seem to work usefully with it (although I can still check with the particular font we use). I checked others (e.g. full-width macron) but there doesn't seem to be a combining form that's useful.

And it seems like only the width text metric from the spec is supported in some cases. Presumably we could do a calculation based on the fontSize our library already calculates which might enable us to vertically place the overline.

(Another option might be to hack something with the textBaseline and "overprinting".)

(As a side note,fabric.js has apparently implemented over line/text-decoration support but bringing in a whole library for overline seems like overkill.)

[follower]

I hacked together a quick test using the OCRA font and Unicode (e.g. "W\u{0305}P\u{0305}") which seems to partly work:

For some reason the overlined text seems to result in use of a completely different (and narrower) font. (I changed the labels so the difference can be seen between "WP" with an overline and without.) No idea why this occurs...

The overline seems pretty thin so we might be better to draw it ourselves anyway...

Due to the font oddness there doesn't seem to be a clear "winner" in implementation at this stage.

[dave5]

i'd run with that implementation and note that it's a suboptimal fix. create a new issue to look into fonts in a later round of work.