https://bugs.documentfoundation.org/show_bug.cgi?id=153907
Bug ID: 153907
Summary: Apply add-or-remove spaces when searching for font
(families)
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
(This is an issue I'm experiencing in the context of importation of PDFs, but I
actually think it's more generally relevant.)
Some font families have names which are sequences of multiple words, e.g.
Adobe's "Minion Pro" (an OpenType version of their Minion PostScript font). But
such sequences often someone get mangled into no-spacing character sequences,
e.g. "MinionPro". There are probably multiple reasons why this can happen;
quite possibly something to do with input filters for file formats, but maybe
already in the file being opened. Anyway, this happens.
So, it is not uncommon for LO to open a document which has a font of the
"FooBar" family, while the system has font of the "Foo Bar" family - or even
vice-versa: The document has "Foo Bar", your system has "FooBar".
I believe that in these cases, and when an exact match of the family name is
not found, LO will, fall back on the spaces-on or spaces-off alternative
respectively.
There are probably multiple places in the code where this heuristic could be
applied. Obviously within input filter code, but also when you "just" open an
ODT, in choosing which font to display with - so something like an implicit
font substitution rule? Let developers decide.
PS - It's not even a search for a lot of font family name combinations: Just
one extra combination for removing spaces, and as many combinations as there
are capital-separated words, i.e. FooBarMS would make us look for:
FooBarMS,
FooBar MS, Foo BarMS, FooBarM S,
Foo Bar MS, FooBar M S, Foo BarM S
Foo Bar M S
although maybe we could be more conservative with that.
--
You are receiving this mail because:
You are the assignee for the bug.
