Re: 2.6.x font rendering busted with no display or Xvfb

I committed a fix to STABLE that improves things and fixes some memory
leaks. But there is still not WYSIWYG.

I think the fundamental problem is that we're not allocating the same
font maps when not using X11.

The solution I see for this is to always use FT2 font maps on X11 for
measuring stuff even if we drawing with X11 allocated fonts.

Martin

On Fri, Jun 13, 2008 at 4:46 AM, J.M. Maurer <uwog@uwog.net> wrote:
>
> Some information that Dom asked on the ML that might help someone:
>
> The DPI of the normal X case was 89, 100 for Xvfb, and 72 for no-X.
>
> Now the interesting bit: when I hardcode all 3 codepaths in
> gr_UnixPangoGraphics.cpp to use 89 DPI, the output from all 3 cases are
> different. The difference being in the horizontal character positioning
> and the line height (which also differs a lot).
>
> I'd expect the output from all 3 to be the same.
>
> </clueless>
> Marc
>
>
> On Thu, 2008-06-12 at 19:31 +0200, J.M. Maurer wrote:
>> Hi all,
>>
>> With 2.4.x, AbiWord couldn't run without an X server (for example for
>> command line conversions). However, when you used Xvfb things were
>> perfectly fine.
>>
>> With 2.6.x we don't have the X display dependency anymore. However, when
>> you do a command line print, the results are quite bad when not using
>> the standard X server.
>>
>> Testcases for a sample document (http://uwog.net/~uwog/test.abw):
>>
>> 1) Command line conversion with a normal X server works perfectly:
>>
>> http://uwog.net/~uwog/test-normal.pdf
>>
>> 2) Command line conversion with Xvfb: font rendering looks quite off
>> (spacing):
>>
>> http://uwog.net/~uwog/test-Xvfb.pdf
>>
>> 3) Command line conversion with no DISPLAY: *really* crappy font
>> rendering:
>>
>> http://uwog.net/~uwog/test-noX.pdf
>>
>> Does anyone have a clue what is going on here? Any workaround (like 2.4
>> +Xvfb was) would be appreciated as well.
>>
>> Thanks,
>> Marc
>>
>
>
Received on Sun Jun 15 02:57:14 2008