Apache OpenOffice (AOO) Bugzilla – Issue 18664
Whole texts look moving up in Grid Text with Asymmetric DPI
Last modified: 2004-01-29 16:07:06 UTC
Is it possible to always display correct grid texts on any physical resolutions including asymmetric DPI? For example, an initial Redhat9 installation sets Monitor's DisplaySize (under "Monitor" section in /etc/X11/XF86Config) to 330mm x 240mm. (These size settings may depends on linux distributions, monitors, video cards, XFree86 versions etc.) If you perform "xdpyinfo" on this system, it shows: screen #0: dimensions: 1024x768 pixels (333x241 millimeters) resolution: 78x81 dots per inch As you see, physical resolution, or DPI (dot per inch) is set to 78x81, which I call an asymmetric DPI setting. Now with the asymmetric DPI setting, whole texts look moving up (or spaces between characters get narrower) in Grid Text. Please compare the following screenshots: DPI: 78x81 http://www.transwift.net/ooo/rhl9atvt2z.png DPI: 78x78 http://www.transwift.net/ooo/rhl9atvt6f.png Please take a look at the following page for details. http://www.transwift.net/ooo/grid_linux.html I will attach sample texts. Please refer to the grid text and other settings for these texts: http://www.transwift.net/ooo/grid_sample_setting_en.html Now again, is it possible to always display correct grid texts on any physical resolutions including asymmetric DPI? Thanks
Created attachment 8753 [details] Zipped three sample Grid Texts
I added some screenshots on Vine Linux 2.1.5 (OOo1.1beta2), SuSE8.1 and SuSE8.2 (OOo1.1rc4) to the following page: http://www.transwift.net/ooo/grid_linux.html Thanks
.
The fix sounds easy: account for the different x-dpi and y-dpi when adjusting display text to the printer. A problem with the obvious fix is to avoid the related "dancing chars" problem.
changing status
Fix in CWS vcl7pp1r2
Hi hdu, Thanks for your solution. BTW, what is "dancing chars"? Is this also fixed in CWS vcl7pp1r2? Thanks
> BTW, what is "dancing chars"? Text is layouted on the printer and the character positions there will be used to position them on the display. Since both devices have not related resolutions there will be rounding errors. E.g. a text "ab" has the printer positions 0 100 which gets converted to the display positions 0.0 10.4 before and 0 10 after rounding. When the text is now changed to "aab" the printer positions are 0 100 200 and the display positions are 0.0 10.4 20.8 before and 0 10 21 after rounding. So the distance between "a" and "b" is increased by one pixel on the display => the characters seem to be "dancing" > Is this also fixed in CWS vcl7pp1r2? Yes.
pl->sba: please verify in CWS vcl7pp1r2
SBA: Reassigned to Ulf.
SBA: Set status to "Fixed".
hmm. The fix is well thought of, and works in general; but unfortunately the wordprozessor also calculates for a (virtual) printer device, which has a different resolution. In other words: for extreme asymetric resolutions/dpi the problem issue is still visible. Reopening issue.
reassigning issue to hdu.
Changed in CWS vcl7pp1r3, so that slightly different x- and y-resolutions get ignored by moving the x-dpi adjustment to GetResolution() instead of GetScreenFontResolution() on UNX.
HDU->US: please verify in CWS vcl7pp1r3
Changing resolution to fixed in order to mark it verified.
Issue verified in CWS vcl7pp1r3.
ok in master workspace srx645_m27s1-1.8738. Fix will be in forthcoming OOo 1.1.1. Closing Resolved/Verified issue.