|
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
|