[dev] OpenOffice crashes at startup on Windows
Hello! Could you help me to understand why OpenOffice chashes at startup. Now I have only a report from debugger: Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: C:\Users\user\projects\openoffice\OOO340_test\build\wntmsci12.m00\OpenOffice\installed\install\en-US\OpenOffice.org 3\program\soffice.exe Symbol search path is: *** Invalid *** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * Executable search path is: ModLoad: 0111 01c26000 officeloader.exe ModLoad: 7726 7739c000 ntdll.dll ModLoad: 76f2 76ff4000 C:\Windows\system32\kernel32.dll ModLoad: 7548 754ca000 C:\Windows\system32\KERNELBASE.dll ModLoad: 5b30 5b423000 C:\Windows\WinSxS\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\MSVCR90D.dll ModLoad: 75aa 75b69000 C:\Windows\system32\USER32.dll ModLoad: 7742 7746e000 C:\Windows\system32\GDI32.dll ModLoad: 773b 773ba000 C:\Windows\system32\LPK.dll ModLoad: 7714 771dd000 C:\Windows\system32\USP10.dll ModLoad: 7582 758cc000 C:\Windows\system32\msvcrt.dll ModLoad: 76e8 76f2 C:\Windows\system32\ADVAPI32.dll ModLoad: 7747 77489000 C:\Windows\SYSTEM32\sechost.dll ModLoad: 759f 75a91000 C:\Windows\system32\RPCRT4.dll ModLoad: 75d7 769b9000 C:\Windows\system32\SHELL32.dll ModLoad: 75b7 75bc7000 C:\Windows\system32\SHLWAPI.dll (cf4.ffc): Break instruction exception - code 8003 (first chance) eax= ebx= ecx=0028f788 edx=772a64f4 esi=fffe edi= eip=772fe60e esp=0028f7a4 ebp=0028f7d0 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0246 *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - ntdll!LdrVerifyImageMatchesChecksum+0x633: 772fe60e cc int 3 0:000 g ModLoad: 752e 7532b000 C:\Windows\system32\apphelp.dll ModLoad: 773d 773ef000 C:\Windows\system32\IMM32.DLL ModLoad: 758d 7599c000 C:\Windows\system32\MSCTF.dll ModLoad: 752e 7532b000 C:\Windows\system32\apphelp.dll eax=5b354340 ebx=c005 ecx=5b3012c4 edx=5b3012c4 esi=77337380 edi=77337340 eip=772a64f4 esp=0028fab8 ebp=0028fad4 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0246 ntdll!KiFastSystemCallRet: 772a64f4 c3 ret how can I collect more information about crash? -- С Уважением, Дмитрий -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] 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, and 888 ? 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
[dev] Re: __attribute__((packed)) for enum
On 19.05.2011 16:40, tora - Takamichi Akiyama wrote: 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. There's been some tweaking of CJK font metrics in VCL, but I'm not really familiar with that. 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. If you want to shrink everything to make sure you don't generate too many pages, perhaps it's better to reduce the print scale (ATTR_PAGE_SCALE, or PageScale via API). That would apply to simple cells and EditEngine content equally. Niklas -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
