Steps: 1. Open attachment 74244 [details] from bug 51930 Observed behaviour: Second page is missing Reproduced in Version: 5.4.0.0.alpha0+ Build ID: 634589b340316ba64b731b4d923c1056be415494 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Regression introduced by: author Khaled Hosny <khaledhosny@eglug.org> 2016-11-17 13:03:39 (GMT) committer Miklos Vajna <vmiklos@collabora.co.uk> 2016-11-18 07:42:52 (GMT) commit d8c386593e42e1f0cce52d052b1009c59e75afa2 (patch) tree 82979c0e4b3c3bfa98e9e2e488aa4af26725eab6 parent 2ec76e5db5c194e133b6fee5c7f81c04357971f8 (diff) tdf#103944: Fix symbol font remapping This reverts: commit 8556cd881270823865662e9a7700da58d11c2785 Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Thu Mar 6 09:48:54 2014 +0100 cp#1000039 DOC import: ignore symbol charset of the symbol font Otherwise characters unhandled by our OpenSymbol font (like Arabic 0-9 numbers) won't be rendered using an other font, as no other font provides the symbol charset. Do this in SwWW8ImplReader::GetFontParams(), where we already have font name -> font family mappings for a few well-known fonts. The DOCX filter does the same for quite some time, and that's how Arabic numbers in text using the Symbol font were rendered, instead of little rectangles. The reverted commit prevented remapping symbols supported by OpenSymbol, and it seems to have worked incidentally because of the fallback to the “Standard Symbols L” Type 1 font which we longer support. The bug doc is broken in master with or without this commit, but reverting this fixes tdf#103944. Adding Cc: to Khaled Hosny
We are now rendering the document correctly (the Symbol font fallback to OpenSymbol is working) and the whole content fits in the first page, so I don’t see any bug here.
Ouch, it seems MS Office 2010 under Wine displays the content in 2 pages as well. I've just Retested again under Win and the content is displayed in just one page. Sorry for the noise. Closing this as RESOLVED NOTABUG