On 24/03/15 03:40, CVAlkan wrote:
-- Where did you get that order of precedence?
I first stumbled across it, when either « ŉ » or « ŋ » was coming up wrong.
Took some examination of the fonts I had, to figure out what was happening.
One day, when I was feeling extremely venturous, I looked, to no avail,
through the source code, trying to determine where it looked for the
That's why I wanted to confirm that LO ignored its own precedence on Linux systems.
FWIW, On extremely rare occasions, it does the same thing. I think it
might be related to glyphs in the private part of Unicode.
If that's the case, it's another path for inconsistencies in documents
Well, I sort of agree, but my opinion is that you have to have a good set
of formatting primitives (can't think of a better word for this) before you
can build styles --- Styles in that view being a way to insure consistent
use of an identical grouping of primitives.
Also need to add a couple of more formatting primitives. (Rotate base
line 90 degrees, Rotate base line 270 degrees, Rotate base line 180
degrees, Boustrophedon, Reverse Boustrophedon. I've forgotten the rest.)
But my working assumption is that issues with writing systems will be
fixed "real soon now".
Re: You can not get away with setting English, Arabic, and Korean in the
same style ... etc.
-- You're right, you can't RIGHT NOW. But I think we should redesign the
interfaces to make that more transparent). We both know it CAN BE DONE
although we accomplish it with different hacks
First thing that is needed, is for LibO to provide an indication that
the glyph is not found in the font used by the style, and a substitute
is being used.
Just realized that that could be done as an extension. It would need to
check the list, character, paragraph, and cell files.
The same issues crop up in multilingual spreadsheets, as in multilingual
I don't know if it is an issue when using Base.
Using Draw to create text documents has its own set of problems.
(Text documents using Reverse Boustrophedon writing systems can only be
created by using Draw.
It is a toss up whether Write or Draw produces better looking text
documents, for Boustrophedon writing systems. Either way, they are
painful to create.)
it's just that I think we shouldn't need to go through that.
Because of the way the LibO code is written, language has to be declared
in the style. Basically, this is so that grammar checking,
spell-checking and related functions work as expected.
For styles to consistently work as expected, I think that they have to
be writing system dependent. At a minimum, that helps with the missing
glyphs from the font issue.
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
- Re: [libreoffice-users] 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