On 23/03/15 17:38, CVAlkan wrote:
First Question: Is this still true in current versions?
I _think_ so.
Since that is the most heavily weighted attribute in the matching
process, and since null is never equal to null, the matches returned are
Sometimes? I'd suggest that the returns are always inappropriate.
On the other hand, if we use a free Google font such as Droid Sans (which has no foundry
property), we get into trouble.
The scenario you describe is precisely why I have said since at least
2001, that the only way to ensure that the glyphs are right, is to use
language specific styles. You can not get away with setting English,
Arabic, and Korean in the same style, and have things show up correctly.
That works if, and only if one uses a pan-Unicode font for all three
languages and writing systems.
If you want Arabic to display properly, then all three fonts in the
style have to be the Arabic font. If you want Korean to display
properly, then all three have to be set to the same font.
This applies regardless of language & writing system combination you are
return the first font in which it locates the requested language.
The order of precedence is Writing System, then specific glyphs, with a
slight preference for the precomposed glyph, even if you originally did
not use a precomposed glyph.
FWIW, you need to turn both CJKV & CTL on, regardless of what writing
system is being used --- even if writing English. ( "æ", and similar
letter constructions require both CTL & CJKV features.)
Character styles were really not meant for this – that’s what selecting a font is supposed to do.
Character styles fill in the holes that paragraph styles create.
Also useful for one or two words in a different language, or the same
language, but a different writing system.
Has anyone given much thought to permitting finer-grained control of CTL font substitution
IMNSHO, the optimal solution would be to have styles be both language
and writing system dependent.
– e.g. making the CTL font substitutions page similar to
the Options | LibreOffice | Fonts page used for general font substitution of
In other words, permitting multiple fonts to have substitutions defined?
The "bad" workaround is to create a set of character styles, that have
the correct font for each set of glyph(s), and then write a macro that
basically changes each glyph in the document to that of the character
style for the glyph.
I apologize if this sounds like a rant; it's not intended to be
But it bringing up some non-optimal things that have been around since
LibreOffice 0.x was released.
* English - detected
To unsubscribe e-mail to: firstname.lastname@example.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Font versus Character Substitution · Paul D. Mirowsky
Re: [libreoffice-users] Font versus Character Substitution · jonathon
- [libreoffice-users] Re: Font versus Character Substitution (continued)
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy