Created attachment 118688 [details] Bugdoc with PDFs showing import results Opening the RTF in attached archive with LO Writer gives a single page with 4 text paragraphs. Opening it with MS WordViewer gives two-pages calculations document. In LO Writer, selecting all (Ctrl+A) shows in status bar 385 words, 2620 characters selected. Replacing format from MS Sans Serif to Arial (Ctrl+H -> Other options -> Format... -> Font) makes the hidden text visible, so it is actually imported, but initially invisible. The text may also be made visible by selecting eveerything and clearing direct formatting (Ctrl+M) It's impossible to make the text visible by selecting options to show hidden text etc. Tested with LO 4.4.2.2 and 5.0.1.2 under Win7x64 (possible theree's a problem under Win7, where the MS Sans Serif font is absent?)
Can't reproduce. Ubuntu 15.04 x64 LibreOffice Version: 5.0.0.5 Can you try resetting your profile? https://wiki.documentfoundation.org/UserProfile
(In reply to Joel Madero from comment #1) > Can you try resetting your profile? :) Yes, of course, I forgot to mention that. Resetting profile doesn't help; and the problem is reproducible on different PCs. > Ubuntu 15.04 x64 I suspect that the problem may be OS-dependent.
Note that you should not use the “MS Serif” or “MS Sans Serif” virtual fonts, which can’t be printed at all. Those are relics of the Windows 3.1-era operating systems, and are still in Windows for backwards-compatibility purposes. I called them “virtual fonts” because they are not actual fonts you can use; those are raster fonts intended to be used by legacy, 16-bit software (incompatible with 64-bit, of course). The Windows Registry will map those names to real OpenType fonts, namely Arial and Times New Roman, which you can see in the PDF export. Since this is something Windows does internally, it’s neither our fault nor a bug.
(In reply to Adolfo Jayme from comment #3) > Note that you should not use the “MS Serif” or “MS Sans Serif” virtual > fonts, which can’t be printed at all. Those are relics of the Windows > 3.1-era operating systems, and are still in Windows for > backwards-compatibility purposes. This note, although the only true of all the reply, is completely irrelevant. The bug is not about best practices of usage of office suite and fonts; it's about its inability po properly handle existing documents, that are properly formed, however "tasteless". > I called them “virtual fonts” Please continue calling them however you like; it's totally irrelevant here. > because they are not actual fonts you can use; This is false. You prove that in your next passage; it's only *your own* interpretation of term "font" that prevents you treat (stone-age era) raster fonts as fonts you can use. > those are raster fonts intended to be used by legacy, 16-bit software > (incompatible with 64-bit, of course). I tend to agree with the term "legacy", but you fail again when talk about 64-bit incompatibility of those apps. The era of those fonts "ended" only with introduction of Windows 2000 in 1999, when MS made its vectorized variant of that font. But there were 32-bit OSes like Win95, Win98, WinMe and (for those who would like to conquer those OSes' bitness) WinNT4. They used those fonts, so please don't make bold statements that are not true. > The Windows Registry will map those > names to real OpenType fonts, namely Arial and Times New Roman, which you > can see in the PDF export. Since this is something Windows does internally, > it’s neither our fault nor a bug. And this is the first relevant statement here, and it's false again. The Adobe PDF specification, as well as some specific implementation of it, has nothing to do with "Windows Registry mappings" (that MAY exist in SOME versions), Windows "internal processing", as well as with LO inability to show documents having such fonts. If you told that it's OK that LO *USES* those mappings, and that's why the text LOOKS differently than it should, then I would wholeheartly agree. But LO actually DOESN'T show characters of that font IN ANY WAY, not even with ANY OTHER FONT that it's able to display, and that's A BUG. It not only breaks the document formatting (the thing that I would NEVER treat as bug given these circumstances), but it effectively loses information (text), something that could be interpreted as DATA LOSS (because, even though some individuals would find a way to discover "hidden" text, it requires some geekery, and most would simply think that the import lost the data). I revert the status to UNCONFIRMED again.
I'll ask for one other person's input but I'm on the side of closing as NOTABUG as well - there was a very good explanation of what's going on and why it is in no way a bug. But I'll get one additional input. If a third person agrees, please don't reopen it.
(In reply to Mike Kaganski from comment #2) > I suspect that the problem may be OS-dependent. Nope this doesnt happen in Linux and doubt it would happen in OSX, so it is likely Windows only. Version: 5.1.0.0.alpha1+ Build ID: 2639eadce4c9ccead9112a6893b5e9e2e0fefd78 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-09-14_23:56:58 Locale: en-US (en_US.UTF-8)
(In reply to Yousuf (Jay) Philips from comment #6) > (In reply to Mike Kaganski from comment #2) > > I suspect that the problem may be OS-dependent. > > Nope this doesnt happen in Linux and doubt it would happen in OSX, so it is > likely Windows only. I'm afraid there's some misunderstanding. When I wrote "OS-dependent", I meant that it really DOES depend on OS on which it runs. So yes, it's likely Windows-only.
(In reply to Mike Kaganski from comment #7) > I'm afraid there's some misunderstanding. > When I wrote "OS-dependent", I meant that it really DOES depend on OS on > which it runs. So yes, it's likely Windows-only. Yes i had misread you and thought you wrote 'OS-independant'. :D
Confirmed with Word viewer. Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: fi-FI (fi_FI)
(In reply to Mike Kaganski from comment #4) > The bug is not about best practices of usage of office suite and > fonts; it's about its inability po properly handle existing documents, that > are properly formed, however "tasteless". Mike, I’ve never called on “best practices” here… > Please continue calling them however you like; it's totally irrelevant here. Yes, you love the word “irrelevant”, I get it. And it was only meant as an didactic explanation; I didn’t intend to use the exact technical terms. > This is false. You prove that in your next passage; it's only *your own* > interpretation of term "font" that prevents you treat (stone-age era) raster > fonts as fonts you can use. Bikeshedding! > > those are raster *fonts* intended to be used by legacy, 16-bit software > > (incompatible with 64-bit, of course). > > I tend to agree with the term "legacy", but you fail again when talk about > 64-bit incompatibility of those apps. I did not talk about 64-bit incompatibility of ANY application. I was talking about the binary blobs that have the .fon extension, which are in fact 16-bit-compiled software. The 16-bit software, according to MSDN documentation, is not supported by the Windows-on-Windows (WoW64) compatibility shim, and 64-bit LibreOffice (nor any 64-bit app) will not pick that format up for this reason. Sorry if I was explaining myself badly. > > The Windows Registry will map those > > names to real OpenType fonts, namely Arial and Times New Roman, which you > > can see in the PDF export. Since this is something Windows does internally, > > it’s neither our fault nor a bug. > > And this is the first relevant statement here, and it's false again. The > Adobe PDF specification, as well as some specific implementation of it, has > nothing to do with "Windows Registry mappings" (that MAY exist in SOME > versions), Windows "internal processing", as well as with LO inability to > show documents having such fonts. Again, you seem to be picking things I did not say. I’ve never talked about the PDF Specification; I referred instead to Registry mappings in Windows that cause, for instance, that Windows can’t use a font called “Helvetica” even if you install it – it will change your document to Arial, inadvertently, for on-screen rendering and/or printing/PDF export. This depends on the software, I’ve tested several Office versions on this along the years. > If you told that it's OK that LO *USES* those mappings, and that's why the > text LOOKS differently than it should, then I would wholeheartly agree. But > LO actually DOESN'T show characters of that font IN ANY WAY, not even with > ANY OTHER FONT that it's able to display, and that's A BUG. Agreed that failing to display text in any way is a bug. But my whole point is that there’s a set of external circumstances external to us that would justify a “NOTOURBUG” status. I’ll keep this open, but keep in mind that it’s very unlikely that it has a factual impact on large-scale deployments (I’m yet to see any organization that mandates the use of those fonts for document production). This bug is very localized as I see it, because it could only affect those documents produced years ago in now-obsolete software, so I’ve assigned a priority of Lowest.
Cannot reproduce anymore with 5.1.2.2 -> resolved worksforme.