https://bugs.documentfoundation.org/show_bug.cgi?id=94203
Adolfo Jayme <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|medium |lowest --- Comment #10 from Adolfo Jayme <[email protected]> --- (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. -- 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
