When row labels have an underscore sign ("_"), sometimes it doesn't show

Issue #336 new
Anastasia Baryshnikova created an issue

USE CASE: WHAT DO YOU WANT TO DO?

See all the row labels properly

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

Open a matrix file and set the label size to a large value. Unfortunately, I can't reproduce the issue exactly, but after playing around with label size you can get it to a point that you can see all the labels but not their underscore sign.

underscore_problem.png

CURRENT BEHAVIOR

Some underscores are visible, some are not. The underscore in the red label (the one hovered on) is always visible.

EXPECTED BEHAVIOR

All symbols in the labels should always be visible.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

Calculate the position of the background box for each label using the pixel positions of the data:

start = getPixel(index);
height = getPixel(index + 1) - getPixel(index);

instead of using getScale() for the height and the start being calculated based on the center pixel.

FILES AFFECTED (where the changes will be implemented) - developers only

LabelView

LEVEL OF EFFORT - developers only

medium

COMMENTS

Comments (14)

  1. Robert Leach

    I figured out the pattern of what is happening: the background of the label below is drawing over the underscore of the label above when the data row "width" varries. When the width of the row below is 1 less than the one above, the font's center is 1 pixel higher and thus the top of the font is 1 higher and overwrites the lowest pixel row of the label above it.

    I'm not sure whether the font size needs to change, though that may be necessary. It might be that simply the drawing of the background needs to change. Instead of using a static width/height for the background for all labels, we can probably calculate the width/height each time based on the scale and the position. That should do it.

  2. Robert Leach
    • edited description

    Added the developer section to the ticket based on the diagnosis in the comments.

  3. Robert Leach

    These steps to reproduce should work.

    1. Open test_dataset3.txt
    2. Select label settings as depicted here:

      underscore_issue_label_settings.png

    3. Zoom/scroll to this position:

      underscore_issue_test_dataset3_zoom.png

    4. Select an area in the matrix that includes all labels with underscores.

  4. Robert Leach

    Made progress on figuring this out.

    First of all, the whizzing labels appear to draw nicely with no occluded underscores (though there are some minor background yellow highlighting issues when it comes to drawing the overrun arrows).

    But the underscores are being drawn over by the method that draws the background of the label "below" the label with an underscore. Part of the issue involves the varying number of pixels per row/column. Another part of the issue however is that we've been using getAscent() instead of getMaxAscent(). Each returns a number of pixels that the fond extends up from its baseline, but some characters will draw above what the getAscent method returns. I didn't know this, nor did I know about getMaxAscent (above which no characters will draw), so I had noted tops & bottoms of characters extending above & below the highlight background and had implemented some fudge factors to capture them.

    I should be able to adjust the code to use the max method, however I like the way the fonts are currently spaced and I don't think that that should change. It means that characters like pipes and underscores might collide between labels, which is fine except when it comes to highlighting with a background color change. So here's what I think I should do:

    1. The background color boundaries should match the boundaries of the data, even if bars and underscores break these boundaries.
    2. Backgrounds should all be drawn before any text is drawn so that underscores are not drawn over.
    3. Label text position should be calculated more accurately and account for variations in col/row thickness to err on the side of drawing the text a bit higher so that underscores are less likely to go below the highlight
    4. Overrun arrow thickness should be based on getAscent/getDescent
    5. Remove fudge factors
  5. Log in to comment