Re: 5.2 rc2 tarball now available

[Daniel J S. <dan...@ie...>]

On 07/04/2017 02:29 PM, Dmitri A. Sergatskov wrote:
> On Tue, Jul 4, 2017 at 2:05 PM, sfeam <sf...@us...
> <mailto:sf...@us...>> wrote:
>
>
>     More to the point...  Is it only the "test" command that has a problem?
>     If so I don't think we really care that much.  If boxed text in
>     general is
>     failing that would be a bigger issue.
>
>
> ​Here is the output of a script;
>
> ​set label "1234567890" at 0,-0.4 boxed font "DejaVuSans, 5"
> set label "1234567890" at 0,-0.2 boxed font "DejaVuSans, 7"
> set label "1234567890" at 0,0 boxed font "DejaVuSans, 9"
> set label "1234567890" at 0,0.2 boxed font "DejaVuSans, 12"
> set label "1234567890" at 0,0.4 boxed font "DejaVuSans, 14"
> set label "1234567890" at 0,0.6 boxed font "DejaVuSans, 18"
> set label "1234567890" at 0,0.8 boxed font "DejaVuSans, 24"
> plot sin(x)
>
> One can see that the problem is still there at very small (and perhaps
> very large) font sizes.
> ​The problem seems to be qt related. It looks fine reploted  to e.g.
> pngcairo.

With a rudimentary browsing of the code, it doesn't seem to me that we 
should expect the boxed text to be too accurate.  As for the test image, 
it's

     /* test width and height of characters */
     (*t->linetype) (LT_SOLID);
     newpath();
     (*t->move) (x0 + xmax_t / 2 - t->h_char * 10, y0 + ymax_t / 2 + 
t->v_char / 2);
     (*t->vector) (x0 + xmax_t / 2 + t->h_char * 10, y0 + ymax_t / 2 + 
t->v_char / 2);
     (*t->vector) (x0 + xmax_t / 2 + t->h_char * 10, y0 + ymax_t / 2 - 
t->v_char / 2);
     (*t->vector) (x0 + xmax_t / 2 - t->h_char * 10, y0 + ymax_t / 2 - 
t->v_char / 2);
     (*t->vector) (x0 + xmax_t / 2 - t->h_char * 10, y0 + ymax_t / 2 + 
t->v_char / 2);
     closepath();

which is only a rough estimate at the font-processed string width in 
pixels, assuming a constant-width character.  The test image code should 
be placing a box similar to the way in with text/label items are placing 
a box.

But even in the case of labels with the "boxed" qualifier, I don't see 
any mechanism for either feeding the string width from the terminal back 
to gnuplot so that it can draw a box, or specifying to the terminal that 
it should put a box around the text it is requesting.  That is, the 
proper Qt mechanism is to use a QFontMetrics, in particular its 
boundingRect() function which accepts a string as an input.  E.g.,

https://stackoverflow.com/questions/8633433/qt-get-the-pixel-length-of-a-string-in-a-qlabel

gnuplot Qt terminal does appear to attempt such a thing by:


#ifdef EAM_BOXED_TEXT
exit(25);
		if (m_inTextBox) {
			m_currentTextBox |= rect;
			m_currentBoxRotation = m_textAngle;
			m_currentBoxOrigin = point;
		}
#endif

[snip]

		case TEXTBOX_OUTLINE:
			/* Stroke bounding box */
			outline = m_currentTextBox.adjusted(
				 -m_textMargin.x(), -m_textMargin.y(),
				  m_textMargin.x(), m_textMargin.y());
exit(26);
			rectItem = addRect(outline, m_currentPen, Qt::NoBrush);
			rectItem->setZValue(m_currentZ++);
			rectItem->setTransformOriginPoint(m_currentBoxOrigin);
			rectItem->setRotation(-m_currentBoxRotation);
			m_currentGroup.append(rectItem);
			m_inTextBox = false;
			break;

However, with your test example, the above code doesn't get called.  So 
there are certainly some issues for Qt terminal.

Ethan, how well developed is the boxed label/text?  Is this something 
that needs more development and better left for a next release?  Or 
should a proper Qt fix be a simple matter?

Dan