Created attachment 115572 [details] Original.xlsx Windows 7 Version: 5.0.0.0.alpha1+ Build ID: 5b3a30f40a7ce476922649b734f6ede1c2fdef4b TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-05-13_01:52:36 Locale: en-US (en_US) 1) Open Original.xlxs with LibreOffice 2) Compare column widths (for instance C and D) to Original.pdf or open the Original.xlsx file in Microsoft Office 2013 Observe: Column width is too narrow and text is cut off (e.g., C12, D17)
Created attachment 115573 [details] Original.pdf
Created attachment 115577 [details] Screenshot with pdf and LIbreOffice view. Sorry @Joel, but as I see is the same as in the pdf. It's easy to see if Menu/Tools/Options/LibreOffice calc/View - Display - Text overflow is disable. A bit better in LibreOffice than in the pdf. To me not a bug. Please if you are not agree reopen it.
Crap your right about the pdf - but if you open it in MSO 2013 - that's not what you see. I'll add a screenshot... Maybe a bug in Microsoft Office?
Created attachment 115578 [details] Screenshot of MSO 2013
I talked to Markus about this - he said even if the pdf renders like we show - if we show different from MSO does than we should report and mark as NEW. Moving back to UNCONFIRMED until someone can confirm it's different from the attached screenshot
Sorry @Joel, I never had MSO, 123 since 1983. Can be the issue with the font?. Seems it's the same issue with column B. A change in the column with it's strange. Maybe a first comprobation could be verify if it is the same width with both programs. Column C has 64,84 mm. with LibreOffice, and has the same opening with ApacheOo
Additional proof that column widths are incorrectly imported: 1) Open Original.xlsx in LibreOffice 2) Go to sheet "Combined Output" 3) Look at the merged cell in B5 Compare the wrap/text placement to "Sheet2.pdf" - you can see that the text is wrapped differently in LibreOffice due to the difference in column size.
Created attachment 115586 [details] Sheet2.pdf
Created attachment 115592 [details] Screenshott with zoom 100% in LibreOffice For me it depends on the LibreOffice zoom level. At zoom 100% like in the attached screenshoot it's fine, reducing zoom at 90% it changes. (attached in next comment).
Created attachment 115593 [details] Screenshott with zoom 90% in LibreOffice
Confirmed the zoom issue. However, D17 has cut off text even with 100% zoom as even mario's screenshot shows. I'll set to NEW. Info about how MSO calculates column width & height: https://support.office.com/en-us/article/Change-the-column-width-and-row-height-db30658d-0c0b-44ad-825f-55f1cb4d9957 Ubuntu 15.04 64-bit Version: 5.0.0.0.alpha1+ Build ID: 51d16cc69d8ad9065f61d108ea25d6a025a2e228 TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-05-17_03:58:58 Locale: en-US (en_US.UTF-8)
I think I promised Joel to look into this one after fixing my other document.
So, this one requires some more work by me. Inside OOXML the column width is stored as multiple of the longest character from the set "01234567890". In our import we currently make the assumption that we don't need the character length which of course results in wrong values during the import.
(In reply to Markus Mohrhard from comment #13) > So, this one requires some more work by me. > > Inside OOXML the column width is stored as multiple of the longest character > from the set "01234567890". In our import we currently make the assumption > that we don't need the character length which of course results in wrong > values during the import. That analysis was wrong. We are actually getting the character widths. So now I'm back to zero understanding what is going wrong.
Please test with a daily build and a screen ruler that the column width values from calc and excel are the same for you now. I had to use one ugly hack to get the last problem fixed and hope that this one is working across all machines.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=16726a1b37df8bdcae02b3c7699df814977222bd better algorithm for OOXML column width import, tdf#91267 It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Joel Madero from comment #4) > Created attachment 115578 [details] > Screenshot of MSO 2013 D17 of the first sheet still has the last L cut off a bit (the bottom bar of the L to be exact!) at 100% zoom. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 83eb114394879cbfd073322a51c47d02553c1fcf TinderBox: Win-x86@39, Branch:master, Time: 2015-05-22_06:33:51 Locale: fi-FI (fi_FI)
Note: This file is made with the Calibri font. I've seen terrible formatting ánd printing issues with xlsx files based on Calibri when that font was not available. Perfect example of vendor-lockin. If Carlito and Caladea are installed one can set Tools > Options > LibreOffice > Fonts replacement table: Calibri by Carlito Cambria by Caladea
Well if the goal is perfect interoperability for these templates - we need to figure out how to correctly handle Calibri (the alternative of telling every user who ever uses a MSO 2013 template to go find another font, while ideal in the open source world, is not practical or realistic in the current atmosphere).