Re: __attribute__((packed)) for enum

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 [email protected]
For additional commands send email to [email protected]
with Subject: help