From: Bastian M. <bma...@we...> - 2011-02-24 12:12:41
|
Am 24.02.2011 08:02, schrieb Benjamin Lindner: >> working with the windows terminal I noticed that it places characters >> significantly lower than other terminals. The reason for this is that >> this terminal places text with respect to the baseline of the font, >> whereas other terminals seem to place fonts wrt the bottom of the >> character cell. Why is the behaviour of the windows terminal not correct? > > What exactly is not correct? > Are you referring to subscripting text? > Or do you mean that text positioned at x,y is actually placed below y? > Or do you mean the vertical alignment of e.g. ytic labels is shifted downwards? > Yes, the vertical placement of strings wrt to the tics for example is different for windows. Relative placement within (enhanced) text is fine. This is why I checked when this turned up: version 4.0 has TA_BOTTOM alignment and version 4.2 onward use TA_BASELINE. > The latter is due to the fact that gnuplot determines the height of > the character to be displayed using the GetTextExtent API which > returns the nominal total height of the font in question *not* of the > string/character under test, and is thus too large. > Try setting > GetTextMetrics(hdc,(TEXTMETRIC FAR *)&tm); > cy = lpgw->fontsize; > in wgraph.c:MakeFonts(), and compare the positioning of the ytic labels > > >> Anyway, this probably means that we should revert my changes from almost >> exactly 5 years back and replace TA_BASELINE with TA_BOTTOM in >> src/win/wgraph.c. Makes me wonder why nobody (including me) noticed this >> earlier. > > Are you really sure that this is the correct way of doing it? > IIRC tex sets charaters wrt to the baseline of the font, and not the > bottom line. > The bottom line varies from character to charater, the baseline by > definition not. > So setting 'a' followed by 'g' wrt to the bottom line would shift the > 'g' upwards which certainly is not what's intended, isn't it? > You are correct. Simply using TA_BOTTOM is not the solution. But I am not talking about placement of different characters within a string (using the same font and size). That is done correctly in both cases since all characters of a font share the same box. But it does no longer work with TA_BOTTOM if you change fonts or sizes. This is why I changed the windows code from TA_BOTTOM to TA_BASELINE when I introduced enhanced text for the windows terminal. Otherwise this would not be on the same baseline: set label 1 at 1, 4 "Will {/*2 this} be {/*4 aligned}{/*5?}" The problem becomes apparent given this information from Hans-Bernhard Bröker: "Actually, no. The terminal API defines the reference to be the center line of the font (basically the upper edge of an 'm'). That's what many of those offsets by lpgw->vchar / 2 are about. See "vshift" also. " So this is what I meant: the windows terminal interprets the vertical placement of the string with respect to the baseline, whereas the gnuplot core code expects alignment wrt to the centre of the character box. This gets more obvious if you look at the output of "test": "wxt" eg. puts the test string "123456..." vertically centred, whereas for "windows" it is clearly shifted down. That aside, there seem to be rather strong disagreements about the vertical placements of enhanced text. Try the following script on different terminals: set termoption enhanced set xrange [0:10] set yrange [0:10] set xtics 1 set ytics 1 set grid set label 1 at 1, 8 "y=8: Is {/*2 this} text {/*4 aligned}{/*5?}" set label 2 at 1, 6 "y=6: What about {/=24 Symbols} {/Symbol=24 abcdef} {/Symbol=48 ghijklm}?" set label 3 at 1, 4 "y=4: Normal big label in 32pt" font ",32" set label 4 at 1, 2 "y=2: Normal big label in 64pt" font ",64" plot NaN not It tried this with `font "Arial/Helvetica, 16pt"` and found large differences between windows, wxt, pngcairo, png (classic) and postscript. I am convinced that those differences cannot be explained solely by the different knowledge terminals have about the fonts. Some observations: png: keeps the baseline stable for all labels, but displays label 3 and 4 in 16pt. The vertical position seems to be determined by the first character. pngcairo: label 3 is centred, whereas labels 1 and 2 are shifted downwards. label 1 does not even touch the y=8 line. label 3 and 4 look vertically centred. wxt: not the same as pngcairo postscript: Vertical position seems to be centred wrt to the bounding box of the label. Those are admittedly extreme test cases. But as a user I would expect more consistent behaviour. Bastian |