From: Stephen Viles (sviles_abi@iinet.net.au)
Date: Mon Oct 06 2003 - 04:36:06 EDT
6/10/03 2:55:00 AM, Jordi Mas <jmas@softcatala.org> wrote:
>Hello,
>
>I have just uploaded a New Windows binary candidate release build at:
>
>http://www.softcatala.org/~jmas/setup_abiword.exe
>
>This build fixes bugs 5748 (major graphic class problems) and 5527 (i18n spell
>checking).
>
>Please, test it and let us know how it feels.
http://bugzilla.abisource.com/show_bug.cgi?id=5578#c11 reports the following:
--- I compared the screen displays and the printed outputs from this new version on the attachment file with 1.99.6. They appear to be identical to each other and to the Wordpad displays. That is, we are right back where we started with 1.99.6. I can't see any difference.I also tried a new attachment file "Sentences to test ...". I have not tested its printing under 1.99.6, but otherwise it too seems to behave the same as under 1.99.6.
The nightly HEAD build (2003-09-28) from http://abiword.pchasm.org/abiword/builds/nightly/ was a lot closer to what we want. It appeared that all the characters were within 1 pixel of the correct position in the screen display (if we take the printed version as "correct"). (However, I did just discover that build does very strange things if the zoom is not 100% when the document is first opened.)
Suggestion: It looks like Windows can't shift a character a fraction of a pixel, it positions in whole pixels only, as observed in my comments on the 2003-09-28 build. If we must have a kludge, how about making up the position errors in the white spaces between the words? So all the words would be in the right place, but there might be some errors of +/- 0.5 pixel per character in the widths of characters within each word.
Hope this is some help. ---
http://bugzilla.abisource.com/show_bug.cgi?id=5578#c8 reports:
--- Stephen, I just tried the test file mentioned above on the the nightly HEAD build (2003-09-28) from http://abiword.pchasm.org/abiword/builds/nightly/ per your comment.
The good news:
- The line length on the printed version appears to be the same as the line length on the screen version.
- Zooming does not affect the number of characters that wrap at the end of line on the two lines where this occurs.
- The cursor is positioned correctly relative to the characters of the line.
The bad news:
- The printed characters are a fraction of the size that they should be. i.e the characters appear to be positioned correctly for the specified font size, but each character is much smaller in size than the specified size. The printed size appears to be in proportion to the specified point size, but by eyeball is about 40% to 50% of that specified size.
- The screen presentation looks bad in that the characters are not spaced equally. e.g. in the 12 point "m" line, every fourth "m" is positioned slightly closer to the preceding character than the other three "m"s. It looks like the m is taking up e.g. 13.75 pixels, and to achieve that average spacing, three out of four characters are given 14 pixels, while the fourth is given 13 pixels. The results is rather ugly. I'm not an expert on graphical display techniques , but it would be better if some antialiasing technique could be used to position each character in the correct postion. Does the Windows API take care of anti-aliasing? I understand that current video cards have the capability built in.
All the above may be yesterday's news to the developers, but I post it for what it is worth in the hope that it is helpful. ---
This archive was generated by hypermail 2.1.4 : Mon Oct 06 2003 - 05:08:08 EDT