Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Settle on 1 unicode name library and make it a requirement #1341

Closed
davelab6 opened this issue Apr 26, 2014 · 2 comments
Closed

Settle on 1 unicode name library and make it a requirement #1341

davelab6 opened this issue Apr 26, 2014 · 2 comments
Labels
clarifying feature

Comments

@davelab6
Copy link
Member

It seems from #1322 that we get variant crash/no crash based on the availability of different unicode libraries. This is a poor situation to be in.

Therefore I propose that as part of @frank-trampe 's upcoming stable release, we make @JoesCat 's unicode library a mandatory dependency, so we don't get into this situation again.
@JoesCat
Copy link
Contributor

JoesCat commented Apr 26, 2014

On April 25, 2014 11:12:25 PM Dave Crossland wrote:

It seems from #1322 that we
get variant crash/no crash based on the availability of different
unicode libraries. This is a poor situation to be in.

You also need to consider the internal tables and files, like unicoderange.c
which are build in unison/synchronized with a particular unicode table.

For example, the current FontForge is synchronized with Unicode 6.3, but
there will soon be a unicode set 7.0.

Ideally, FontForge should adapt to the different libuninameslist tables
because they do have different numbers of blocks, lengths, etc.
Not so much a problem with Linux or BSDs if compiled when needed, but more
of a problem with pre-compiled binary versions of FontForge, such as
Windows, MACs, and the various distros that have binary downloads
available.

JoesCat added a commit to JoesCat/fontforge that referenced this issue Jun 9, 2014
@JoesCat
Skip test for pkg-config. test for uninameslist.h and libuninameslist.
3b7cd23 
Some distros are not completely configured correctly for pkg-config.
There is a school of thought that argues for using PKG_CHECK_MODULES,
but that is not necessary. The standard way to check if a library
exists and to link against it is to use AC_CHECK_LIB(), and also check
for the developer header file(s) using AC_CHECK_HEADERS().

Fixed fontforge_create_pkg-config.m4 to only include libuninameslist as
a dependecy ONLY if it exists AND user didn't say no to include it.

This comes to a hard-stop if user wants libuninameslist, but it's not
available. This also tests for version 0.3 and 0.4 of libuninameslist

Libunicodenames was placed in '#' (commented) since it was going to be a
fair bit of re-write to work-around the repeated AC_DEFINE in configure.ac
Issue fontforge#1341 recommends sticking with 1 library rather than support both,
and libunicodenames seems to be limited in function access and OS choices.
Users that want to use libunicodenames can move the comment '#' to switch
libraries for one or the other (see configure.ac) since the active code
is still in place if you want to use the other library, or if there is
another library in future, shouldn't be hard to modify for others:
FONTFORGE_ARG_WITH_LIBUNINAMESLIST
#FONTFORGE_ARG_WITH_LIBUNICODENAMES
@JoesCat JoesCat mentioned this issue Jun 17, 2014
Closed
@skef
Copy link
Contributor

skef commented Jun 20, 2019

This has been argued back and forth and the stance continues to be adjusted over time.

@skef skef closed this as completed Jun 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
clarifying feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@davelab6 @JoesCat @adrientetar @skef