Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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 inappropriate.

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
using.

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
missing fonts. 
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.

jonathon

  * English - detected
  * English

  * English

 <javascript:void(0);>


-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.