Arch Linux User Repository

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

How is this different from libeb?

• It optionally supports UTF-8 extension in addition to EUC-JP, the original libeb does not offer UTF-8 extensions.

• It can also optionally compress books/files using libdeflate method, as opposed to libeb's default and only zlib method. Compression via libdeflate method are potentially better, without incurring excessive performance overheads.

• The patch file contained within libeb has some fixes by the upstream maintainer of libebu.

• It has support for colour swatches on Kojien dictionary.

• Documentation, MO files (generated via the likes of PO or POT) has been largely converted into UTF-8, ensuring consistency to avoiding "mojibake".

Where is the UTF-8 extension support?

• Presently it is not available, primarily due to language barriers. The methods of enabling it appears to also not be straightforward. That said, suggestions to address that are welcome.

Why does this conflict with the other libebu package?

• The binaries and libraries share the exact same name, yet uses different compression algorithms. This makes it as a suitable candidate for split package.

Split package are not supposed to have multiple build parameters!

• There are examples that exists in official Arch repository, in which the first example is the one I chose to base this split package on.

Will this conflict with libeb?

• From a cursory glance on a locally built libeb, the filenames are largely missing an extra character "u", e.g. ebuzip, ebuappendix, etc. That said, it should not conflict, but ideally you should also not have these two packages installed, to prevent possible conflicts.

Why does large portions of the PKGBUILD looks like it is a straight-up copy of libeb?

• It is heavily inspired by libeb PKGBUILD, of which it is largely required to make the packaging process successful. I have not tested on modifying much of prepare(){} or build(){}, other than adding UTF-8 file conversions for consistency, and split the packages as necessary. The LDFLAGS is done to avoid namcap giving warning about lacks GNU_PROPERTY_X86_FEATURE_1_SHSTK. That said, I welcome any suggestions to change these, provided that they would not cause issues with the likes of makepkg.

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

How is this different from libeb?

• It optionally supports UTF-8 extension in addition to EUC-JP, the original libeb does not offer UTF-8 extensions.

• It can also optionally compress books/files using libdeflate method, as opposed to libeb's default and only zlib method. Compression via libdeflate method are potentially better, without incurring excessive performance overheads.

• The patch file contained within libeb has some fixes by the upstream maintainer of libebu.

• It has support for colour swatches on Kojien dictionary.

• Documentation, MO files (generated via the likes of PO or POT) has been largely converted into UTF-8, ensuring consistency to avoiding "mojibake".

Where is the UTF-8 extension support?

• Presently it is not available, primarily due to language barriers. The methods of enabling it appears to also not be straightforward. That said, suggestions to address that are welcome.

Why does this conflict with the other libebu package?

• The binaries and libraries share the exact same name, yet uses different compression algorithms. This makes it as a suitable candidate for split package.

Split package are not supposed to have multiple build parameters!

• There are examples that exists in official Arch repository, in which the first example is the one I chose to base this split package on.

Will this conflict with libeb?

• From a cursory glance on a locally built libeb, the filenames are largely missing an extra character "u", e.g. ebuzip, ebuappendix, etc. That said, it should not conflict, but ideally you should also not have these two packages installed, to prevent possible conflicts.

Why does large portions of the PKGBUILD looks like it is a straight-up copy of libeb?

• It is heavily inspired by libeb PKGBUILD, of which it is largely required to make the packaging process successful. I have not tested on modifying much of prepare(){} or build(){}, other than adding UTF-8 file conversions for consistency, and split the packages as necessary. The LDFLAGS is done to avoid namcap giving warning about lacks GNU_PROPERTY_X86_FEATURE_1_SHSTK. That said, I welcome any suggestions to change these, provided that they would not cause issues with the likes of makepkg.