Use ebu library for EPWING dictionaries

[data-man]

I've tested some dicts with ebu-4.5 library from http://green.ribbon.to/~ikazuhiro/dic/files.
Windows libs should be compiled separately.

[xiaoyifang]

I think the great difficulty here is most linux distributions or macos does not provide eb/ebu precompiled library.

[xiaoyifang]

how to compile libebu on windows? I have not succeed in compile it.

[vedgy]

A comment under mvf/qolibri#38 suggests that libebu is not much better than libeb. Why should it replace libeb in GoldenDict? Perhaps just add optional support for building against libebu in epwing_book.* and goldendict.pro, without touching bundled libeb in maclibs and winlibs?

[data-man]

Sorry. I don't use GD anymore.

[nonwill]

Perhaps just add optional support for building against libebu in epwing_book.* and goldendict.pro, without touching bundled libeb in maclibs and winlibs?

There is no difficulty in porting to libebu, only the name of C header files/lib should be changed in the GD source/pro files. I have been using libebu for several years, but don't feel any discomfort, and also users of GD++ did not report any problems about libebu. The biggest issue is that libebu is a private project with no public VCS repo and also without CI based builds.

[vedgy]

What are the advantages of libebu over libeb?

[nonwill]

The big advantage is that it has built-in support for utf8 encoding of EPWING content(but now few EPWING dictionaries were built with utf8 encoding).

[nonwill]

And the biggest problem with libeb is that it is not thread-safe, and libebu may have made some optimizations for this.

I do not understand Japanese(comments in libebu codes), so I didn't go deep into libebu's codes to confirm that.

[vedgy]

@nonwill, do you have any English-language references that explain the state and issues with libeb, recommend replacing it with libebu? I just found this one: https://aur.archlinux.org/packages/ebu

I think the first step is to allow to optionally build GoldenDict against libebu and let GNU/Linux distributions try switching to libebu, if they feel like it. Then the distros' experience and bug reports (or lack thereof) can guide the decision to replace (or not) the bundled libeb files.

[vedgy]

Interestingly, there are 28 votes for libeb and 0 votes for ebu in AUR. This is probably because several AUR packages depend on libeb but none on ebu. Given such lack of clarity, the start should be optional, off-by-default libebu support. Judging by the changes in this PR, such optional support should be easy to implement.

[nonwill]

do you have any English-language references that explain the state and issues with libeb, recommend replacing it with libebu?

NO, I have not. I think that those Pinned Comments from https://aur.archlinux.org/packages/ebu are just enough.

tuxsavvy commented on [2021-01-05 17:27 (UTC)](https://aur.archlinux.org/packages/ebu#comment-784591) (edited on 2021-01-05 17:27 (UTC) by [tuxsavvy](https://aur.archlinux.org/account/tuxsavvy))
What is this package?

This is a package that contains modified EB Library in which it can handle books that comply with the [JIS X 4081 UTF-8 extension](http://green.ribbon.to/~ikazuhiro/dic/jisx4081u.html)

How is this different from [eb-library](https://aur.archlinux.org/packages/eb-library/)?

It supports UTF-8 extension in addition to EUC-JP, the original eb-library can only deal with EUC-JP.

It can optionally compress books/files using DEFLATE method, as opposed to eb-library's zlib method. By compiling with --enable-libdeflate during ./configure, you can enable such method and potentially create smaller overall compressed file as opposed to using zlib compression.

It is compatible with eb-library. However it is difficult to link both at the same time from the same program, because of conflicting function names for instance. Except for UTF-8 support, it works in the same way as eb-library, so it is usually not necessary to link both at the same time. Ultimately, the names of respective programs has been renamed accordingly to avoid conflicts.

It has support for [colour swatches](http://green.ribbon.to/~ikazuhiro/lookup/lookup.html#EBLOOK) on Kojien dictionary.

It is a modernised equivalent to the abandoned eb-library, which has not seen updates/changes by the original project maintainer for a long time. It also has fixes applied that were reported on Debian's bug report, including [this one](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833085).

This is its official introduction, in Japanese:
http://green.ribbon.to/~ikazuhiro/dic/ebu.html

I think the first step is to allow to optionally build GoldenDict against libebu and let GNU/Linux distributions try switching to libebu

Given such lack of clarity, the start should be optional, off-by-default libebu support

Totally agree with it.
As for the Window platform (also applicable to macOS and Linux), it is very simple to integrate libebu into project. Here is the pro project file from my obsolete nwDeployed repo which can be used for reference:

CONFIG -= qt warn_on
CONFIG += exceptions_off rtti_off warn_off
TEMPLATE = lib

TARGET = ebu

CONFIG += static
win32:DEFINES += HAVE_DIRECT_H HAVE_MBSTRING_H DOS_FILE_PATH

#include($${PWD}/../nwDeployed.pri)

INCLUDEPATH += $${PWD}/ebu
win32:INCLUDEPATH += $${PWD}/win32

SOURCES += ebu/appendix.c \
    ebu/appsub.c \
    ebu/bcd.c \
    ebu/binary.c \
    ebu/bitmap.c \
    ebu/book.c \
    ebu/booklist.c \
    ebu/color.c \
    ebu/copyright.c \
    ebu/cross.c \
    ebu/eb.c \
    ebu/endword.c \
    ebu/error.c \
    ebu/exactword.c \
    ebu/filename.c \
    ebu/font.c \
    ebu/hook.c \
    ebu/jacode.c \
    ebu/keyword.c \
    ebu/lock.c \
    ebu/log.c \
    ebu/match.c \
    ebu/menu.c \
    ebu/multi.c \
    ebu/narwalt.c \
    ebu/narwfont.c \
    ebu/readtext.c \
    ebu/search.c \
    ebu/setword.c \
    ebu/stopcode.c \
    ebu/strcasecmp.c \
    ebu/subbook.c \
    ebu/text.c \
    ebu/widealt.c \
    ebu/widefont.c \
    ebu/word.c \
    ebu/utf8.c \
    ebu/zio.c

HEADERS += ebu/appendix.h \
    ebu/binary.h \
    ebu/booklist.h \
    ebu/defs.h \
    ebu/eb.h \
    ebu/error.h \
    ebu/font.h \
    ebu/text.h \
    ebu/zio.h


EBNET_SOURCES = ebu/ebnet.c \
    ebu/multiplex.c \
    ebu/linebuf.c \
    ebu/urlparts.c \
    ebu/getaddrinfo.c \
    ebu/dummyin6.c

contains(DEFINES, ENABLE_EBNET) {
SOURCES += $$EBNET_SOURCES
}

#INCLUDEPATH += $${PWD}/../zlib/include
LIBS += -lz

[vedgy]

Given such lack of clarity, the start should be optional, off-by-default libebu support

Totally agree with it.

Created #1635 that implements this idea.