Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood a =C3=A9crit :
> Timoth=C3=A9e Lecomte wrote:
>  =20
>> So, the bug only appears when the rendering method is set to
>> 'Antialiasing and oversampling', right ?
>>    =20
>
> correct.
>
>  =20
>> Can you tell me if a font of size 200 with 'Antialiasing and
>> oversampling' looks exactly the same as a size of 10 without
>> 'oversampling' ?
>>    =20
>
> It does not look _exactly_ the same. The font appears to be the same si=
ze
> but on switching there is some slight movement in exact positions of te=
xt.
> It is very slight an I can only notice it because I watch it switch.
>  =20
Ok, I was interested in the size in particular. So it seems the=20
oversampling scale is somehow not applied to the text on your setup.=20
That's strange...
Could you please try the demo 'enhancedtext.dem' and tell me if it shows=20
the same issue ? (the text goes through a slightly different code path=20
for the enhanced text mode).

Another question, most likely unrelated : what's your screen dpi ?=20
(dots-per-inch, this info is given by 'xdpyinfo' for example)

>>
>>    =20
>>> If I make the changes to the rendering method and then resize, withou=
t
>>> closing/reopening the result is unpredictable, including: huge fonts,
>>> only some text displayed, graphics become pixelated, even a lockup.
>>>  =20
>>>      =20
>> Indeed. For this to work as expected, I would have not to change the
>> internal variables immediately, but schedule the change for the time o=
f
>> the next plot. Maybe I should do that before the release...
>>    =20
>
> it would be desirable from my point of view.
>  =20
This is committed.

Best regards,

Timoth=C3=A9e