https://bugs.documentfoundation.org/show_bug.cgi?id=94203
Mike Kaganski <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED CC| |[email protected] Resolution|NOTABUG |--- --- Comment #4 from Mike Kaganski <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
