On 27/10/2016 14:55, CVAlkan wrote:
answer to your question might be: if you were to fix all of those things,
you probably wouldn't encounter the unwarranted and unexpected font substitutions.
If it wasn't so big, Unifont would make a good test case.
Maybe I can figure out how to do bulk editing of the meta-data.
.pdf or save the file as an .fodt; in either case the actual font being used
I'll add that (.fodt) to the list of formats to save documents in.
For one project I'm working on, getting the characters to behave
themselves is a huge problem. So much so, that I've wanted for a macro
that could change the character style of a glyph, according to its
Unicode Code Point.
font to see what's in it, but they are all fairly tedious if you want to
compare some arbitrary set of fonts, and involve looking at one font at a time.
Running a script, or set of scripts that export data to a text file,
then looking at the results, is probably the simplest/fastest way to
deep the water was that I was stepping into, the choice of bash would likely
Donald Knuth said that the only way to write software, was to write the
program three times, changing programming languages at least once.
a short list of some of the things it has to say about itself. The results
so far are rather fascinating, and tend to confirm your suspicion/hope/guess
that fixing the fonts may fix the problem.
('el' and 'hi') for this example. BUT: DejaVuSans-ExtraLight.ttf is missing
the 0x0559 character from the available character bit map. Not knowing
Armenian, I don't know what to make of that, but it's interesting.
The most probably reason for an otherwise complete weight, with other
weights in the same typeface including the missing glyphs, is designer
FreeSerifItalic doesn't report the ISO 15924 script tag 'grek' and FreeMono
fails to report the code 'armn'; DejaVuSansMono-Oblique and FreeMonoOblique
don't report either 'el' or 'hi'. You can see that answering your question
would require some serious experimentation: are there valid reasons some
members of these families are slightly different from others, etc?
The Unicode Standard allows for some designer leeway, in both how the
glyphs are constructed, and how they interact with each other. That
might be what is happening here.
2) I have found two versions of Garamond on my system using this script (I
don't believe I would have done that, so I suspect that different apps may
have added them not realizing the other was there).
That gets into font metadata, and a program might look for something
specific, and failing to find it, automatically downloads and installs
the font that contains what it was specifically looking for.
The base font for one reports it's in a 'Normal' style, while the other says it's 'Regular.'
Those are two different weights. Without looking at them, my guess is
that "Regular" is the inferior looking one.
questions remain: how the heck would I ever have stumbled across this?
This is where one uses a utility that generates a chart of all installed
fonts in one's system, and then looks at which fonts it claims are
installed, and what they look like.
I've forgotten which font management utility for Linux includes that
that the underlying utilities may never have been updated to handle extended
values, but that's just a guess.
Look at how they handle the multi-coloured emoji of Unicode 9.0.
OTOH, that is perhaps unfair, because most font utilities for *Nix are
fixated on Unicode 5.0, or earlier.
If I were ever to mix Thai and Laotian in the same document
They require different IMEs, so most people that put fonts together,
won't combine them in the same typeface.
my guess is that substitution problems will pop up immediately.
For reasons I've yet to track down, however, it isn't even on the list of fonts considered as
One probably needs to update a database somewhere.
Finally, I have some hesitation in modifying any particular font, since as
far as I know they could be overwritten at any time by a helpful app or OS.
This is where running
sudo /usr/share/fonts rm * -R
sudo cp /media/theme/fonts/default/* /usr/share/fonts/*
ensures that only the fonts that one wants are installed.
It seems preferable that if any font errors are found, that they be vetted,
confirmed and corrected by the original creating entity.
This depends upon who/what created the font in question.
For some of those US$5K fonts I've seen, even looking for "errors" in
the font is a breach of the license.
Unfortunately, I'm not sure how all the existing "faulty" versions
could ever be rounded up and destroyed.
You give the corrected font a new, higher version number, and hope that
users will start using the updated font. Trying to destroy faulty
versions, is playing whack a mole. There are better things to do with
one's time and energy.
there is a way for me to pass my bash script along - assuming you have
access to a linux machine (or the Windows 10 bash shell experiment???), let
Is it on GitHub? if so, that might be the easiest.
Otherwise send it as an email attachment.
Box, or dropbox might be easier than email.
I use Linux. Windows is way to frustrating for me to use.
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] Struggling with Hebrew in LO · Dotan Cohen
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