From: msevior@physics.unimelb.edu.au
Date: Sat Oct 04 2003 - 11:17:46 EDT
> Martin,
>
>> YES YES YES please fix this this! I suspect the fix is less than 50
>> LOC. We would all love to release AbiWord 2.0.1 with all our lovely
>> bugfixes and a kick-arse Windows binary.
>
> Some findings:
>
> 1. If I define NEW_SCALE to 0 at gr_Win32Graphics.cpp and I activate the
> #define _UL(x) pGr->tlu((x)) and #define _UUL(x) (x) = pGr->tlu((x))
> macros at
> gr_Win32CharWidths.cpp it works fine.
>
> It seems that the problem is the new scaling code.
>
Hi Jordi,
PLEASE look at what pG->tlu(x) does.
UT_sint32 GR_Graphics::tlu(UT_sint32 deviceUnits) const
{
return static_cast<UT_sint32>((static_cast<double>(deviceUnits) *
static_cast<double>(getResolution()) /
static_cast<double>(getDeviceResolution())) * 100. /
static_cast<double>(getZoomPercentage()) + 0.5);
}
See that getZoomPercentage() call? If you put a call to tlu in
gr_Win32CharWidths class then your charwidths are going to change with
zoom.
Try this simple test. With your changes, load up a document of at least 15
pages.
Change the zoom to a number of different values. Does the document look
the same at all zooms? Do the lines break at the same points at all zooms?
Do you have exactly the same number of lines on the last page at all
zooms?
On the Unix build you do because the charwidths have no dependence on the
zoom value. The charwidths used for the layout of the text on the screen
are the same at all zooms and for printing as well as typing. The Windows
FE should do the same. It's a challenge for us to come up with code which
does this for Windows. I'm certainly not saying the code I wrote must be
preserved but I am saying that whatever you write CANNOT USE tlu() in the
GR_Win32CharWidths class.
On CVS HEAD the Unix build now instantly zooms no matter how big the
document because we can simply replace one graphics class with another and
repaint the screen. Since the layout is independent of zoom this works
perfectly.
That tip for negative logfont is great please apply that.
I'm fairly sure your problem with runs being overwritten comes from some
code paths in the
GR_Win32Graphics::drawChars(const UT_UCSChar* pChars,
int iCharOffset, int iLengthOrig,
UT_sint32 xoff, UT_sint32 yoff,
int * pCharWidths)
method which for some reason to do with specific Windows configurations
is not using the pCharWidths supplied.
As I said, on my WinME box and on other Windows configurations the problem
with the overlapping runs does not happen. I've asked Oliver Schurr to
investigate and he agrees with me. We simply don't see the bug.
> 2. Forcing a negative value at lfHeight value of the LOGFONT[1]
> structure makes Abiword to display a much more clean fonts and to work
> much much better in my configuration. The negative value at the font
> height makes the font mapper transforms this value into device units
> and matches its absolute value against the character height of the
> available fonts.
>
Thanks for investigating this Jordi, please apply the negative logfont patch.
> However, the charwiths of some chars at some zoom values are still to
> wide.
>
> Please, apply the patch and tell me how it fells.
>
I'm sorry I won't commit code that puts calls to tlu in
GR_Win32CharWidths. However you are the Win32 maintainer and if after
your best efforts you
can't find another solution, do what you feel you should do.
Best Regards,
Martin
This archive was generated by hypermail 2.1.4 : Sat Oct 04 2003 - 11:38:21 EDT