On July 2, 2017 08:51:16 AM jrbastien via fontforge-users wrote:
> Joe, I would like to know what the French version does actually? I was
> in the impression that it would provide French names for the glyph in
> Fontforge (for instance "acute" would become "aigu".I followed your
> build instruction but I cannot see any change in FF after that.
At the moment, if you are running a post-20120731 version of FontForge, it
doesn't do anything right now since the code to load it was stripped-out.
If you are running a distro that is still running the older FontForge, then
you will see it, however, when we migrated to the newer autoreconf/automake
system, almost all of the plugins were removed in favor of a built-in
model. You could see some of the code here in function inituninameannot():
https://github.com/fontforge/fontforge/blob/baa54526cbde28a9490f735b9cce51eb612f309c/fontforge/start.cThere are still some distros and operating systems running the older
20120731 version, but many have managed to cross that large barrier of
migration to running and/or building from this current ./bootstrap method,
so this is why you aren't seeing French right now.
I am not 100% sure, but you might be able to run UMAP (see sourceforge),
which is older code that I think works on the same library, so I suspect
you should be able to see it without mods.
There are pros and cons to removing the dynamic library loading, but that
is a different subject.
In terms of quickly answering your question, the quickest cheat to viewing
what you want to see right now is to swap the filenames of Namelist.txt and
ListeDesNoms.txt, then rebuild with ./buildnameslist to rebuild a "French"
nameslist.c, and from here, just 'make' and 'make install' a mangled
libuninameslist library so you can view the French "7.0" then.
In terms of a longer view approach to this problem, we could search for and
re-introduce the stripped-out pieces of code from 20120731, but ideally, we
need an improved solution to fix a couple of problems all at once.
1st problem I see is how do you keep users happy using older lists like 7.0
when we currently have 10.0 available? going from 8->9->10 we're looking at
7500+8500 more characters, plus all the various edits along the way.
From what I understand, I think there may be a similar Chinese version in
similar disrepair.
2nd problem, is the complexity of dealing with various languages when
working with scripts - this gets messy, and fontanvil decided to simplify
with, let's just do English, published by unicode.org (based in France).
In terms of the longer view approach, I think we could probably let
libuninameslist deal with these problem by doing something like:
serve the French translation, and maybe English too at the same time, and
for whatever is not available in French, to use the English version.
New Code will need to be written for this, and appropriate switches in
FontForge as well. Existing code can be left alone so that it outputs
English-only for scripting and current uses.
If you're interested in this, you may want to:
do a 'diff' of Nameslist.txt(ver7) and Nameslist.txt(ver10) to see just how
much change you're looking at to bring the French Listedesnomes.txt 7.0 up
to about the same level as the unicode.org ver 10 of Nameslist.txt
I estimate more than 15000 lines of improvement to ListeDesNoms.txt
The Chinese version is probably at about ver<=5.0, so it needs even more.
The code ideas mentioned for libuninameslist allows for a mix of older info
supported by newer info. If you/anyone have extra suggestions, or is
interesting in coding these new APIs....?
Hope this answers the question(s),
Joe
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
fontforge-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fontforge-usershttp://fontforge.10959.n7.nabble.com/User-f8781.html
Locked
