Hi Niklas,
Am 18.05.2011 13:44, schrieb tora - Takamichi Akiyama:
The motivation of this topic comes from a different point. I have been
looking for a way to prevent a well-known phenomenon "A single sheet
that fits in a A4 paper with Excel turns into two or four A4 papers with
Calc."
On 2011/05/18 22:18, Niklas Nebel wrote:
Four pages means that both width and height are wrong? They are handled quite
differently.
Column widths in Calc are static (stored in twips internally). The conversion
from Excel's character-based units is done during import.
Yeap, "8888" and "8888888" ?
Automatic row heights are updated based on cell formats and contents. The edit engine is
used only for complex cell contents. With simple cells, we "cheat" a bit and
avoid the OutputDevice::SetFont call, for performance reasons. The calculation is based
on the height of the default font (determined from an OutputDevice once), the direct
value from the font height format, and some tweaking, see lcl_GetAttribHeight in
sc/source/core/data/column2.cxx. This obviously leaves lots of room to arrive at
different values from Excel. In some cases even correctly so, because optimal height is
supposed to fit the cell content with your current setup (system, installed fonts).
I appreciate your explanation on the inside of Calc.
As you pointed out, the installed font might be one of the factors. Excel files
are prepared on Windows while I am trying to open them on CentOS and/or
Solaris. Those systems have a different font set.
Another point that I have been suspecting since OpenOffice.org 2.x is artificial
"Ascendant." The vcl module had implemented a feature that mathematically produced an
artificial "Ascendant" of glyph.
Compared with typical Western font files which usually have certain amount of
ascendant, typical Japanese font files have an ascendant of value zero from,
probably, historical reasons.
To make implementation of the upper layer applications such as Writer, Calc, and Impress,
the underlying module, "vcl," tries to internally take care of the differences.
It is good, but, I feel, the artificial ascendant, thus, virtual text height,
might be slightly higher than its expectation. That might lead a cause to
slightly increase unnecessary amount of row height.
BTW, in contrast to the topic on "artificial ascendant," what I have been
currently aiming at is that how to create an preview image of Microsoft Office files
running on back-end servers without any user interaction.
For the purpose, which might be better?
(a) One spreadsheet is converted into a single too-small image file.
(b) One spreadsheet is converted into two or four image files.
Reducing a font size right before calling OutputDevice::SetFont seems to work.
I am trying this attempt for a while.
Regards,
Tora
--
-----------------------------------------------------------------
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help
