http://openoffice.org/bugzilla/show_bug.cgi?id=117344
--- Comment #6 from [email protected] 2011-03-15 17:39:30 --- I am running OpenOffice on Linux, and I had wrongly assumed that all the Windows fonts are there because I have the ttf-mscorefonts-installer package. However, it turns out that mscorefonts does NOT include Lucidia Sans Unicode, which is what I had specified for the upper line because its diacritics are clearer than those of Times New Roman and Arial etc (and I hadn't realised it wasn't there because #45128 has not yet been implemented, and I can't just set a good free font that DOESN'T come with Windows because Word format font embedding #20370 has not yet been implemented). So I guessed Linux-based OpenOffice's substituting another font for Lucidia Sans Unicode is why its save to Word format sometimes specifies slightly-too-narrow widths for the boxes. BUT: 1. When I tried copying Windows/Fonts/l_10646.ttf from a Windows partition to /usr/share/fonts/truetype/ (hence making the real Lucidia Sans Unicode available) and restarting OpenOffice, this did NOT fix the problem. Completely removing my ~/.openoffice.org directory and letting it create a new one still didn't fix it. I know the system has seen the new Lucidia Sans Unicode font because it's now listed in the Gnome desktop preferences, but I don't know how to confirm that OpenOffice has seen it. 2. When I try creating the exact same document but specifying Arial instead of Lucidia Sans Unicode, I still get some frames that are too small. So the problem is NOT specific to Lucidia Sans Unicode (and Arial is definitely in msttcorefonts). 3. The above theory does not explain why OpenOffice itself (on Linux) shows the frames as too narrow when reopening the .doc file after saving it itself. If the problem were purely because of OpenOffice's inaccurate idea of font widths, then at least OpenOffice itself should not show the frames as too narrow when it re-opens the document, because OpenOffice should surely be able to fit its slightly-too-narrow fonts into the slightly-too-narrow size that it itself calculated using those exact same fonts, shouldn't it? Further investigation showed: 1. A frame containing the line "yī ge" generates a frame width of 1.03cm, which shows as too narrow when loaded. But the line "Yī ge" generates a frame width of 1.04cm and displays OK when loaded. And manually setting the "yī ge" width to 1.04cm instead of 1.03cm causes it to display OK. 2. The line "yi ge" also generates 1.03cm and does not display properly until this is revised to 1.04cm. This is a pure ASCII line, so the problem is not with the diacritics. 3. Lines "y", "yy", "yyy", "yyyy" and "yyyyy" all display OK. Each "y" increases the frame width by 0.25cm. 4. Lines "iiiii" and "iiiiii" fail. They generate frame widths of 0.59cm and 0.71cm respectively. These need to be increased to 0.60cm and 0.72cm before the display is OK. "iiiiiii" generates a frame width of 0.82cm and displays OK. I then tried changing the measurement type to "points" instead of "cm". The too-narrow frame width of "yi ge" now said 29.25 points (585 twips, 1.031875cm). From a casual look at the source code, I know that OpenOffice internally works in twips (1/20 point), which is why a setting of, say, 29.26 points does not stick (reverts to 29.25). So I tried setting to 29.30 (586 twips, 1.03363888...cm) and it displayed OK. It seems somebody somewhere is calculating the width of a string in some other unit, converting to twips, and rounding DOWN (surely it makes more sense to round UP whenever bounding boxes are concerned?) I saw the following code in ww8par6.cxx (in the v3.3 source tarball at http://download.services.openoffice.org/files/stable/3.3.0/OOo_3.3.0_src_core.tar.bz2 ) : SwTwips nNewWidth = MoveOutsideFly(pSFlyPara->pFlyFmt, *pSFlyPara->pMainTextPos); if (nNewWidth) pSFlyPara->BoxUpWidth(nNewWidth); so as a possible workaround, I tried changing that last line to: pSFlyPara->BoxUpWidth(nNewWidth+1); but I am having difficulty building the result on Ubuntu 10.10. I did: apt-get install libarchive-zip-perl libcupsys2-dev libpam-dev gperf libfreetype6-dev libx11-dev libxaw7-dev libfontconfig1-dev libxrandr-dev bison flex libgconf2-dev libgnomevfs2-dev ant openjdk-6-jdk ./configure --disable-mozilla --disable-gtk --without-junit --prefix=/opt/openoffice.org3 ./bootstrap . LinuxX86Env.Set.sh cd instsetoo_native && build --all and it turned out I also needed to do: ln -s /usr/include/libxml2/libxml /usr/include but I'm now getting: Entering /tmp/OOO330_m20/sax/source/expatwrap Making: sax.uno.so /usr/bin/ld: cannot find -lexpat_xmlparse /usr/bin/ld: cannot find -lexpat_xmltok despite the fact that I have libexpat1-dev. Not sure what to do about this. Can someone who has a working Linux build environment try the above +1 hack? -- Configure bugmail: http://openoffice.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Bugzilla. Please log into the website and enter your comments. ----------------------------------------------------------------------- ----------------------------------------------------------------- To unsubscribe send email to [email protected] For additional commands send email to [email protected] with Subject: help -- ----------------------------------------------------------------- To unsubscribe send email to [email protected] For additional commands send email to [email protected] with Subject: help
