Re: [libreoffice-users] Re: Struggling with Hebrew in LO

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
examine them.

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

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

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

No doubt.

> For reasons I've yet to track down, however, it isn't even on the list of fonts considered as 
> substitutes;

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.

jonathon


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